From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UV3S8-0007kn-1g for qemu-devel@nongnu.org; Wed, 24 Apr 2013 13:26:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UV3S6-0004kb-Ht for qemu-devel@nongnu.org; Wed, 24 Apr 2013 13:25:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UV3S6-0004kS-3E for qemu-devel@nongnu.org; Wed, 24 Apr 2013 13:25:54 -0400 Date: Wed, 24 Apr 2013 13:25:44 -0400 From: Luiz Capitulino Message-ID: <20130424132544.55875393@redhat.com> In-Reply-To: <5178071E.7020908@redhat.com> References: <1366731014-48790-1-git-send-email-jfrei@linux.vnet.ibm.com> <1366731014-48790-2-git-send-email-jfrei@linux.vnet.ibm.com> <5176ABB7.8080102@redhat.com> <20130424115022.2ac2667d@redhat.com> <5178071E.7020908@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] Split out dump-guest-memory memory mapping code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Peter Maydell , Ekaterina Tumanova , Alexander Graf , qemu-devel , Rabin Vincent , Christian Borntraeger , Jens Freimann , Paolo Bonzini , Andreas =?UTF-8?B?RsOkcmJlcg==?= On Wed, 24 Apr 2013 10:23:58 -0600 Eric Blake wrote: > On 04/24/2013 09:50 AM, Luiz Capitulino wrote: > >> This raises an interesting question about introspection - how will > >> management apps (such as libvirt) be able to determine whether the > >> paging command is supported for a given architecture? Do we need to > >> expand the 'MachineInfo' QMP datatype so that 'query-machines' can tell > >> us whether a given machine will support or reject attempts to set > >> 'paging':true during 'dump-guest-memory'? > > > > Is libvirt going to query this for the automatic dump feature? > > Probably. Right now, libvirt has already exposed the paging option to > users, and uses the try-and-fail approach of reporting back any error > message from QMP if the dump command fails. But we've had error reports > in the past against libvirt that the error reported by qemu isn't always > the sanest, and that sometimes it is much nicer to have libvirt detect > in advance that a qemu command cannot succeed than it is to do a > try-and-fail approach. There's also a matter of clean rollbacks; > libvirt has to set up some state when starting a dump command, and has > to undo that state if try-and-fail reported an error; whereas a > capability detection can avoid having to set up any state in the first > place. Fair enough. So, we have to choose a good and consistent method for reporting arch-dependent capabilities. I like what you suggest, but there are two issues with it. First, we're adding query--capabilities commands for some commands, so I feel that reporting this capability through MachineInfo is inconsistent. The other issue is that, if we do add this capability to MachineInfo, then we'll have to add future arch-dependent capabilities to MachineInfo as well. I'd prefer query-dump-guest-memory-capabilities myself, although I'm unsure if the proliferation of such commands is a good thing.