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

[Dor Laor <dlaor@redhat.com>]

On 03/02/2011 12:25 PM, Jes Sorensen wrote:
> On 03/01/11 15:25, Dor Laor wrote:
>> On 03/01/2011 02:40 PM, Anthony Liguori wrote:
>>>
>>> On Mar 1, 2011 7:07 AM, "Dor Laor"<dlaor@redhat.com
>>>   >  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.
>
> I had a few thoughts about this already, which I think will work for
> both spice and vnc. What we could do is to expose the video memory via
> shared memory. That way a spice or vnc daemon could get direct access to
> the memory, this would limit communication to keyboard/mouse events, as
> well as video mode info, and possibly notifications to the client about
> which ranges of memory have been updated.
>
> Using shared memory this way should allow us to implement the video
> clients without performance loss, in fact it should be beneficial since
> it would allow them to run fully separate from the host daemon.

Why do you call it a daemon? Each VM instance should have only one, the 
'host daemon' naming is misleading.

The proper solution long term is to sandbox qemu in a way that there 
privileged mode and non privileged mode. It might be implemented using 
separate address space or not. Most operations like vnc/rpc/spice/usb 
should be run with less privileges.

The main issue is that doing it right will take time and we'll want 
virt-agent be merged before the long term solution is ready. The best 
approach would be gradual development

>
> Cheers,
> Jes
>