linux-kernel - Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4CD44759.5020500@collabora.co.uk>
Date:	Fri, 05 Nov 2010 18:05:13 +0000
From:	Ian Molton <ian.molton@...labora.co.uk>
To:	Anthony Liguori <anthony@...emonkey.ws>
CC:	linux-kernel@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	QEMU Developers <qemu-devel@...gnu.org>,
	virtualization@...ts.linux-foundation.org,
	virtualization@...ts.osdl.org, Alon Levy <alevy@...hat.com>,
	Avi Kivity <avi@...hat.com>
Subject: Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport

On 03/11/10 18:17, Anthony Liguori wrote:
> On 11/03/2010 01:03 PM, Ian Molton wrote:

> Why is it better than using virtio-serial?

For one thing, it enforces the PID in kernel so the guests processes 
cant screw each other over by forging the PID passed to qemu.

>> My current patch touches a tiny part of the qemu sources. It works today.
>
> But it's not at all mergable in the current form. If you want to do the
> work of getting it into a mergable state (cleaning up the coding style,
> moving it to hw/, etc.) than I'm willing to consider it. But I don't
> think a custom virtio transport is the right thing to do here.

Hm, I thought I'd indented everything in qemus odd way... Is there a 
codingstyle document or a checkpatch-like tool for qemu?

I'm happy to make the code meet qemus coding style.

> However, if you want something that Just Works with the least amount of
> code possible, just split it into a separate process and we can stick it
> in a contrib/ directory or something.

I dont see what splitting it into a seperate process buys us given we 
still need the virtio-gl driver in order to enforce the PID. The virtio 
driver is probably quite a bit more efficient at marshalling the data 
too, given that it was designed alongside the userspace code.

>>> I
>>> think we can consider integrating it into QEMU (or at least simplifying
>>> the execution of the backend) but integrating into QEMU is going to
>>> require an awful lot of the existing code to be rewritten.

Why? aside from codingstyle, whats massively wrong with it thats going 
to demand a total rewrite?

>>> Keeping it
>>> separate has the advantage of allowing something to Just Work as an
>>> interim solution as we wait for proper support in Spice.

Why does keeping it seperate make life easier? qemu is in a git repo. 
when the time comes, if it reall is a total replacement, git-rm will 
nuke it all.

>> I dont know why you think integrating it into qemu is hard? I've
>> already done it.
>
> Adding a file that happens to compile as part of qemu even though it
> doesn't actually integrate with qemu in any meaningful way is not
> integrating. That's just build system manipulation.

Uh? Either it compiles and works as part of qemu (which it does) or it 
doesnt. How is that not integrated? I've added it to the configure 
script too.

-Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/