Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism

[Eric Blake <eblake@redhat.com>]

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

On 01/18/2012 08:39 PM, Wen Congyang wrote:
> At 01/19/2012 11:32 AM, Jun Koi Wrote:
>> On Thu, Jan 19, 2012 at 10:50 AM, Wen Congyang <wency@cn.fujitsu.com> wrote:
>>> Hi, all
>>>
>>> 'virsh dump' can not work when host pci device is used by guest. We have
>>> discussed this issue here:
>>> http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html
>>>
>>> We have determined to introduce a new command dump to dump memory. The core
>>> file's format can be elf.
>>
>> do you pause the guest when the dump happen, or you can somehow let it
>> continue to run?
> 
> I pause the guest when the dump happens.
> 
>>
>> would be wonderful if you can do the latter, since dumping a guest
>> memory can take a lot of time.
> 
> Yes, it may tak a lot of time. But we dump a guest memory when the guest
> panics, and there is no need to continue to run the guest.

Would it be possible to have both a dump from a certain point in time
and still allow the guest to run unpaused?

I'm thinking something along the lines of pausing the guest, setting up
control structures, then calling fork().  The parent can then unpause,
and use the control structures to communicate the memory state from the
child back out the monitor.  Meanwhile, the guest has a copy-on-write
clone of the entire memory state, so as long as the control structures
guarantee that the child will not accept any monitor commands and not
resume the guest, then the child process can be used to stream the
memory contents as they were at the time of the dump command back over
the control structure back to the parent process.  I will admit,
however, that following the fork(), you would be limited to
async-signal-safe functions, so it may be a rather difficult task to design.

-- 
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: 620 bytes --]