Re: [Qemu-devel] [RFC][PATCH 09/16 v6] introduce a new monitor command 'dump' to dump guest's memory

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-02-17 17:32, Eric Blake wrote:
> There are other APIs where qemu has ended up pausing the domain and not
> restoring things back to running when done, and where libvirt has had to
> track existing state prior to starting actions in order to manually fix
> things after the fact (see libvirt's qemudDomainCoreDump as a wrapper
> around migration to file, for an example).  If we do things right in
> this new DumpState API, we may want to decide to fix other monitor
> commands to use the same mechanism (it won't offload any of the burden
> from libvirt, which must still correctly interact with older qemu, but
> would make life nicer for clients that can assume the saner semantics).

I think there is no need for a new API. Everything you need is there:
check current state, prevent transitions or invoked handlers on
unexpected transitions. If other commands do not make use of this, they
should probably be fixed.

What command or series of commands do you have in mind?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux