From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUfLu-0001p0-00 for qemu-devel@nongnu.org; Tue, 23 Apr 2013 11:41:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUfLs-0000Rj-A6 for qemu-devel@nongnu.org; Tue, 23 Apr 2013 11:41:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUfLs-0000RX-1I for qemu-devel@nongnu.org; Tue, 23 Apr 2013 11:41:52 -0400 Message-ID: <5176ABB7.8080102@redhat.com> Date: Tue, 23 Apr 2013 09:41:43 -0600 From: Eric Blake MIME-Version: 1.0 References: <1366731014-48790-1-git-send-email-jfrei@linux.vnet.ibm.com> <1366731014-48790-2-git-send-email-jfrei@linux.vnet.ibm.com> In-Reply-To: <1366731014-48790-2-git-send-email-jfrei@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2GRRXGPARINDDODNUVIOR" 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: Jens Freimann Cc: Peter Maydell , Ekaterina Tumanova , qemu-devel , Alexander Graf , Rabin Vincent , Christian Borntraeger , Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GRRXGPARINDDODNUVIOR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/23/2013 09:30 AM, Jens Freimann wrote: > Split out dump-guest-memory memory mapping code to allow dumping withou= t > memory mapping >=20 > The qemu dump.c code currently requires CONFIG_HAVE_CORE_DUMP as well a= s > CONFIG_HAVE_GET_MEMORY_MAPPING. This allows for dumping with and withou= t paging. > Some architectures will provide only the non-paging case. This patch al= lows an > architecture to provide dumping even when CONFIG_HAVE_GET_MEMORY_MAPPIN= G is not > available. To do that, we split out the common code and provide stub fu= nctions > for the non-paging case. If -p is specified on a target that doesn't su= pport it, > we will pass an error to the calling code. >=20 > Signed-off-by: Ekaterina Tumanova > Signed-off-by: Jens Freimann > --- > +++ b/include/qapi/qmp/qerror.h > @@ -249,4 +249,7 @@ void assert_no_error(Error *err); > #define QERR_SOCKET_CREATE_FAILED \ > ERROR_CLASS_GENERIC_ERROR, "Failed to create socket" > =20 > +#define QERR_UNSUPPORTED_COMMAND_OPTION \ > + ERROR_CLASS_GENERIC_ERROR, "Option(s) %s of %s command not support= ed for %s" Rather than adding a new QERR_* constant here, just use error_setg() in qmp_dump_guest_memory() in the first place. 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'? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2GRRXGPARINDDODNUVIOR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRdqu3AAoJEKeha0olJ0Nq2pAIAJo9d96oHhTd/UkeOrsnmnlD F6u00j2yP6mwJvwM6R39tRv/VCzLt2fsJgUEawugIQCzfLShYubnucl/N9EXxAqf +x3YRRGnboW4V8ndIjaTErZedaJZfdLgMlNVa3FsIPvc4COjJpDDu3kgFHEKjlo5 EZD18sg5wdrRN9t11WsedLPAfNKimVZMn8H587CtFI0cdGRNqwDQPczwLzQhrOLN UZkDNCysq7F/A+S/YCqXoRJWcozCO7tuVbw8GwLoO3ar2x3p8FXy+6rHZ1Znzf7t sxZGVfKYajKgIoeYmQpszcLPyLXfkF99mIwEw5bL0Gp3hZGrBzOpwh/2RDs2vXw= =gz64 -----END PGP SIGNATURE----- ------enig2GRRXGPARINDDODNUVIOR--