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

[Alon Levy <alevy@redhat.com>]

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" <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.
> 

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
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.

> Cheers,
> Jes
>