qemu-devel
[Top][All Lists]
Advanced

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

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


From: Dor Laor
Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
Date: Wed, 02 Mar 2011 12:56:00 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 ThunderBrowse/3.3.4

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"<address@hidden
  >  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





reply via email to

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