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
