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

[Jan Kiszka]

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!

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux