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

[Alon Levy]

On Wed, Mar 02, 2011 at 01:04:58PM +0200, Dor Laor wrote:
> 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"<dlaor at 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
> 
> Is that the only DMA do you do? That's good for this model.
> 

Yes. We have two memory bars (another for rom) and an io bar. The bars contain
the framebuffer (primary surface backing store, also used in vga mode), the
non primary surfaces backing store and the rings (display, cursor, and release).

In qxl (native) mode the rings are read/written to all the time, the rest by demand.
In vga mode it's identical to vnc, the framebuffer is written from the guest and
we track the dirty regions.

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

ok, so qxl remains in qemu process. But all those io exits (well, most) end
up as calls to spice-server, now in another process. So latency wise it's the
same.

> >
> >>Cheers,
> >>Jes
> >>
> 
>