[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs su
Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
Wed, 02 Mar 2011 13:04:58 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) 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:58 PM, Alon Levy wrote:
On Wed, Mar 02, 2011 at 11:25:44AM +0100, 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.
I think that would work well for spice. Spice uses shared memory from the
pci device for both the framebuffer and surfaces/commands, but this is
Is that the only DMA do you do? That's good for this model.
not really relevant at this level. What about IO and irq? that would add
additional latencies, no? because each io exit would need to be ipc'ed over
to the spice/vnc process? and same way in the other direction, requesting
qemu to trigger an interrupt in the next vm entry.
The qxl device can be in the privileged qemu (as a start) and it will
handle irqs directly. Even today you need to notify the spice server
thread, so nothing will change
Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features, Jes Sorensen, 2011/03/02