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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Wed, 29 Feb 2012 08:49:10 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

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

Anthony, the only way I can think of solving this is making the screendump
asynchronous. Do you have a different suggestion?

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