From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2eI5-0007BB-8R for qemu-devel@nongnu.org; Wed, 29 Feb 2012 02:49:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2eHl-0006uJ-70 for qemu-devel@nongnu.org; Wed, 29 Feb 2012 02:49:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2eHk-0006tZ-Ut for qemu-devel@nongnu.org; Wed, 29 Feb 2012 02:49:17 -0500 Message-ID: <4F4DD876.1080707@redhat.com> Date: Wed, 29 Feb 2012 08:49:10 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <1330118525-14522-1-git-send-email-alevy@redhat.com> <1330118525-14522-4-git-send-email-alevy@redhat.com> <4F4811CF.7050909@codemonkey.ws> <20120225084607.GA22687@garlic.redhat.com> <20120228171039.36c394a3@doriath.home> In-Reply-To: <20120228171039.36c394a3@doriath.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] add qmp screendump-async List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Alon Levy , armbru@redhat.com, Anthony Liguori , qemu-devel@nongnu.org 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