[Top][All Lists]
[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
- Re: [Qemu-devel] [RFC][PATCH 09/15] introduce a new monitor command 'dump' to dump guest's memory, (continued)
[Qemu-devel] [RFC][PATCH 12/15 v5] support to cancel the current dumping, Wen Congyang, 2012/01/18
[Qemu-devel] [RFC][PATCH 10/15] run dump at the background, Wen Congyang, 2012/01/18
[Qemu-devel] [RFC][PATCH 15/15 v5] auto cancel dumping after vm state is changed to run, Wen Congyang, 2012/01/18
Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism, Jun Koi, 2012/01/19
- Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism, Wen Congyang, 2012/01/18
- Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism, Eric Blake, 2012/01/19
- Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism,
Wen Congyang <=
- Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism, Eric Blake, 2012/01/30
- Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism, Wen Congyang, 2012/01/30