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

[Anthony Liguori]

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 <mailto:address@hidden>>>
> > wrote:
> > >> >
> > >> > 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
> > various
> > >> > 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
> > daemond.
> > >
> > >
> > > 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.

Regards,

Anthony Liguori