On 04/23/2013 07:41 PM, 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 <tuman...@linux.vnet.ibm.com>
Signed-off-by: Jens Freimann <jf...@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'?
as far as I understand libvirt doesn't actually use -p dump-guest-memory
parameter.
and virsh dump doesn't have paging param
