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

[Wen Congyang]

At 10/19/2011 07:40 PM, Jan Kiszka Write:
> On 2011-10-19 04:04, KAMEZAWA Hiroyuki wrote:
>> On Tue, 18 Oct 2011 10:31:10 +0200
>> Jan Kiszka <address@hidden> wrote:
>>
>>> On 2011-10-18 10:31, Wen Congyang wrote:
>>>> At 10/18/2011 04:26 PM, Jan Kiszka Write:
>>>>> On 2011-10-18 10:25, Wen Congyang wrote:
>>>>>> 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.
>>>>>
>>>>> gdb allows you to walk up the frame and print variables (globals &
>>>>> local) etc.
>>>>
>>>> Crash uses gdb to provide common function, and you can also use all the 
>>>> gdb commands
>>>> in crash.
>>>
>>> That what's the added value here when I can use gdb directly?
>>>
>>
>> I didn't read full story but 'crash' is used for investigating kernel core 
>> generated
>> by kdump for several years. Considering support service guys, virsh dump 
>> should support
>> a format for crash because they can't work well at investigating vmcore by 
>> gdb.
>>
>> crash has several functionality useful for them as 'show kerne log', 'focus 
>> on a cpu'
>> 'for-each-task', 'for-each-vma', 'extract ftrace log' etc.
>>
>> Anyway, if a man, who is not developper of qemu/kvm, should learn 2 tools for
>> investigating kernel dump, it sounds harmful.
> 
> Right, that's why everything (live debugging & crash analysis) should be
> consolidated on the long run over gdb. crash is architecturally obsolete
> today - not saying it is useless!

I do not know why crash is obsoleted today. Is there a new better tool to 
instead
crash?

At least, I always use crash to live debugging & crash analysis.

Thanks
Wen Congyang

> 
> Jan
>