Re: [Qemu-devel] [PATCH 4/4] add qmp screendump-async

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

>> There is a hang possible with the current screendump command, qxl, a
>> spice client using libvirt and spice-gtk such as virt-viewer /
>> remote-viewer, where you have:
>> 1. libvirt waiting for screendump to complete
>> 2. screendump waiting for spice server thread to render
>> 3. spice server thread waiting for spice client to read messages
> 
> Which messages?

spice protocol.

>> 4. spice client == libvirt client, waiting for screendump completion
> 
> The way I had understood this problem is that qxl takes a long time to
> perform a screen dump, which would cause the global mutex to be held for
> a long time. If this is really serious, then a async command for it
> makes sense IMO.

That describes it pretty good.  Normal workflow is that spice-server
sends the rendering commands received from the guest off to the spice
client and the actual rendering happens there.  spice-server also keeps
track of the rendering commands so it can actually render on the host
side too of needed (called 'local rendering').  But it doesn't do that
unless it has to to avoid wasting cycles.  Events which need local
rendering are:  (1) display on sdl/vnc, (2) screendump monitor command,
 (3) guest requesting screen content (happens when doing screen shots
for example).

So when issuing the screendump monitor command we have to ask
spice-server to render the screen for us, when it is done we can write
out the screen dump.  We don't want block the iothread while the spice
server is busy does the rendering.

Additionally the local rendering can be delayed by a spice-client
connected via slow network link.  This is (3) in alon's list above.
There are plans to fix that, but it isn't trivial to do due to the way
spice-server keeps track of the rendering commands.  It can delay the
rendering several seconds.  But even without that I've seen delays
around 50ms, which is still way too much to have iothread blocked.

cheers,
  Gerd