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

[Luiz Capitulino]

On Wed, 24 Apr 2013 10:23:58 -0600
Eric Blake <address@hidden> 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-<command>-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.