From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2kzO-0004Qb-Bo for qemu-devel@nongnu.org; Wed, 29 Feb 2012 09:58:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2kzI-0007vl-0I for qemu-devel@nongnu.org; Wed, 29 Feb 2012 09:58:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:23379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2kzH-0007un-OF for qemu-devel@nongnu.org; Wed, 29 Feb 2012 09:58:39 -0500 Date: Wed, 29 Feb 2012 11:58:37 -0300 From: Luiz Capitulino Message-ID: <20120229115837.29e6d1bf@doriath.home> In-Reply-To: <20120229081553.GD8200@garlic> 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> <20120229081553.GD8200@garlic> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Alon Levy Cc: qemu-devel@nongnu.org, Marc-Andre Lureau , armbru@redhat.com, Anthony Liguori , kraxel@redhat.com On Wed, 29 Feb 2012 10:15:53 +0200 Alon Levy wrote: > On Tue, Feb 28, 2012 at 05:10:39PM -0300, Luiz Capitulino wrote: > > On Sat, 25 Feb 2012 10:46:07 +0200 > > Alon Levy wrote: > > > > > On Fri, Feb 24, 2012 at 04:40:15PM -0600, Anthony Liguori wrote: > > > > On 02/24/2012 03:22 PM, Alon Levy wrote: > > > > >This is an across the board change since I wanted to keep the existing > > > > >(good imo) single graphic_console_init callback setter, instead of > > > > >introducing a new cb that isn't set by it but instead by a second > > > > >initialization function. > > > > > > > > > >Signed-off-by: Alon Levy > > > > > > > > What's the rationale for this? > > > > > > 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 display channel messages. > > > > > > 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 is true, but it is not the immediate problem the bz is dealing with > - if it was only this there would be no hang. Well, this kind of hang always smells like a spice threading synchronization problem to me. I thought that I'd be capable of showing that if I really understood what was going on, but I can't, even with your diagram. An asynchronous command solves the global mutex contention problem, but I think this hang should be further investigated, otherwise the async command risks just hiding the real problem.