Re: [Qemu-devel] [PATCH 1/2] Split out dump-guest-memory memory mapping code

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

On 04/23/2013 09:30 AM, Jens Freimann wrote:
> Split out dump-guest-memory memory mapping code to allow dumping without
> memory mapping
> 
> The qemu dump.c code currently requires CONFIG_HAVE_CORE_DUMP as well as
> CONFIG_HAVE_GET_MEMORY_MAPPING. This allows for dumping with and without paging.
> Some architectures will provide only the non-paging case. This patch allows an
> architecture to provide dumping even when CONFIG_HAVE_GET_MEMORY_MAPPING is not
> available. To do that, we split out the common code and provide stub functions
> for the non-paging case. If -p is specified on a target that doesn't support it,
> we will pass an error to the calling code.
> 
> Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
> Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
> ---

> +++ 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"
>  
> +#define QERR_UNSUPPORTED_COMMAND_OPTION \
> +    ERROR_CLASS_GENERIC_ERROR, "Option(s) %s of %s command not supported 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'?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]