qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Question] dump memory when host pci device is used by


From: Wen Congyang
Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
Date: Tue, 18 Oct 2011 16:25:40 +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 10/18/2011 04:19 PM, Jan Kiszka Write:
> On 2011-10-18 09:58, Wen Congyang wrote:
>> At 10/18/2011 03:52 PM, Jan Kiszka Write:
>>> On 2011-10-18 09:15, Wen Congyang wrote:
>>>> Hi, Jan Kiszka
>>>>
>>>> At 10/10/2011 05:34 PM, Jan Kiszka Write:
>>>>> On 2011-10-10 11:02, Daniel P. Berrange wrote:
>>>>>> On Mon, Oct 10, 2011 at 08:52:08AM +0200, Jan Kiszka wrote:
>>>>
>>>>>
>>>>> Run gdb with "set debug remote 1" and watch the communication, it is not
>>>>> that complex. But a dump command is probably simpler for those
>>>>> scenarios, I agree.
>>>>
>>>> I have implemented the command dump and reuse migration's code. But I meet 
>>>> a problem
>>>> when I test it.
>>>
>>> Using migration code for dump is most probably the wrong approach as you
>>> saw through that conflict. All you need are the register states and the
>>> RAM. Reuse gdbstub services for this.
>>
>> Hmm, if the migration code can not be reused, I think we should define a new
>> qemu's vmcore format, and add some codes into crash to support such format.
> 
> Please try to avoid defining something new. Unless there is a striking
> reason, standard gdb core files should be generated so that you can load
> the dump directly into gdb for analysis.

I am not sure whehter the standard gdb core files can not be analyzed by crash.
If not, I think we should define something new because it's easier to use
crash than gdb to analyze the core files.

Thanks
Wen Congyang

> 
> Jan
> 




reply via email to

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