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

[Jens Freimann <jfrei@linux.vnet.ibm.com>]

On Tue, Apr 23, 2013 at 09:41:43AM -0600, Eric Blake wrote:
> 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.

ok, will fix
 
> 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'?

sounds reasonable to me. 


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