[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs su

From: Anthony Liguori
Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
Date: Tue, 01 Mar 2011 09:29:49 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

On 03/01/2011 09:25 AM, Dor Laor wrote:
On 03/01/2011 02:40 PM, Anthony Liguori wrote:

On Mar 1, 2011 7:07 AM, "Dor Laor" <address@hidden
<mailto:address@hidden>> wrote:
> On 02/28/2011 07:44 PM, Anthony Liguori wrote:
>> On Feb 28, 2011 10:44 AM, "Jes Sorensen" <address@hidden
>> <mailto:address@hidden <mailto:address@hidden>>>
>> >
>> > Hi,
>> >
>> > On last week's call we discussed the issue of splitting non core
>> > features of QEMU into it's own process to reduce the security
risks etc.
>> >
>> > I wrote up a summary of my thoughts on this to try to cover the
>> > issues. Feedback welcome and hopefully we can continue the
discussion on
>> > a future call - maybe next week?
>> >
>> > I would like to be part of the discussion, but it's a public holiday
>> > here March 1st, so I won't be on that call.
>> >
>> > Cheers,
>> > Jes
>> >
>> >
>> > Separating host-side virtagent and other tasks from core QEMU
>> > =============================================================
>> >
>> > To improve auditing of the core QEMU code, it would be ideal to be
>> > able to separate the core QEMU functionality from utility
>> > functionality by  moving the utility functionality into its own
>> > process. This process will be referred to as the QEMU client below.
>> Separating as in moving code outside of qemu.git, making code optionally
>> built in, making code optionally built in or loadable as a separate
>> executable that is automatically launched, or making code always built
>> outside the main executable?
>> I'm very nervous about having a large number of daemons necessary to run
>> QEMU.  I think a reasonable approach would be a single front-end
> s/daemon/son processes/
> Qemu is the one that should spawn them and they should be transparent
from the management. This way running qemu stays the same and qemu just
need to add the logic to get a SIGCHILD and potentially re-execute an
dead son process.

Spice is the logical place to start, no?  It's the largest single
dependency we have and it does some scary things with qemu_mutex.  I
would use spice as a way to prove the concept.

I agree it is desirable to the this for spice but it is allot more complex than virtagent isolation. Spice is performance sensitive and contains much more state. It needs to access the guest memory for reading the surfaces. It can be solved but needs some major changes. Adding spice-devel to the discussion.

Yeah, but the viability of this mechanism is dependent on whether it can support something that's complex, just like Spice. Considering that the smaller pieces like VNC or virt-agent are at most a couple thousand of lines of code, whereas Spice is close to a hundred thousand lines, the benefit from moving Spice to a separate address space is significantly higher.

Will virtagent be kept out of tree till we merge spice?

Nothing should be held up from being merged because of an effort to put things in a separate address space. But that's not to say that virt-agent is something that's going to get merged tomorrow. I don't know that there is even an agreed upon architecture at the moment.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]