qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Wen Congyang
Subject: Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism
Date: Mon, 30 Jan 2012 13:40:20 +0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100413 Fedora/3.0.4-2.fc13 Thunderbird/3.0.4

At 01/20/2012 12:34 AM, Eric Blake Wrote:
> 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 <address@hidden> 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.
> 

I do not understand this section. Do you say the reason of allowing the guest
to run unpaused? Or do you say the way to do it?

Thanks
Wen Congyang




reply via email to

[Prev in Thread] Current Thread [Next in Thread]