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

[Wen Congyang <wency@cn.fujitsu.com>]

At 10/21/2011 09:02 PM, Dave Anderson Write:
> 
> 
> ----- Original Message -----
>> At 10/21/2011 03:11 PM, Jan Kiszka Write:
>>> On 2011-10-20 12:03, Wen Congyang wrote:
>>>> At 10/20/2011 05:41 PM, Jan Kiszka Write:
>>>>> On 2011-10-20 03:22, Wen Congyang wrote:
>>>>>>>> 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?
>>>>>
>>>>> I'm not aware of equally powerful (python) scripts for gdb as
>>>>> replacement, but I think it's worth starting a porting effort at
>>>>> some point.
>>>>>
>>>>>>
>>>>>> At least, I always use crash to live debugging & crash analysis.
>>>>>
>>>>> Then you may answer some questions to me:
>>>>>  - Can you attach to a remote target (kgdb, qemu, etc.) and how?
>>>>
>>>> No. crash's live debugging only can work the kernel is live. I can use it get
>>>> some var's value, or some other information from kernel. If kernel panics,
>>>> we can use gdb to attach to a remote target as you said. But on end user machine,
>>>> we can not do it, we should dump the memory into a file and analyze it in another
>>>> machine while the end user's guest can be restart.
>>>>
>>>>>  - Can you use it with latest gdb versions or is the gdb functionality
>>>>>    hard-wired due to an embedded gdb core in crash (that's how I
>>>>>    understood Christoph's reply to this topic)
>>>>
>>>> If I use crash, I can not use latest gdb versions. Do we always need to use
>>>> the latest gdb versions? Currently, gdb-7.0 is embedded into crash, and it
>>>> is enough to me. If the gdb embedded into crash cannot anaylze the vmcore, I
>>>> think we can update it and rebuild crash.
>>>
>>> crash is simply designed the wrong way around (from today's
>>> perspective): it should augment upstream gdb instead of forking it.
>>
>> Cc Dave Anderson. He knows how crash uses gdb.
>>
>> I think that crash does not fork a task to execute gdb, and gdb is a
>> part of crash.
> 
> I'm not sure what the question is, but you can consider crash as a huge

The question is that: 'virsh dump' can not be used when host pci device
is used by guest. We are discussing how to fix the problem. We have determined
that introduce a new monitor command dump. Jan suggested that the core file's
format is gdb standard core format. Does crash support such format? If no,
is it possible to support such format?

Thanks
Wen Congyang

> wrapper around its embedded gdb, which it invokes as "gdb vmlinux", and
> then takes over the user interface.  It doesn't have a clue as to what
> the memory source is, i.e., whether it's one of the almost 20 different
> dumpfile formats that it supports (including "virsh dump"), or if it's
> running against a live system.  It has its own command set, although
> you can enter some gdb commands, write gdb scripts, etc.  But the main
> purpose of the embedded gdb is for the crash-level sources to be able
> to gather data structure information, disassemble text, add-symbol-file
> kernel modules, and so on.  There is no kgdb remote linkage. 
> 
> It's currently embedding gdb-7.0, although as we speak I'm updating it
> to gdb-7.3.1 because the compiler guys have decided that dwarf4 should be
> used by default.
> 
> It would be kind of cool if there was a "/dev/mem"-like interface
> to a KVM guest's physical memory, so that you could sit on a KVM host
> and enter "crash vmlinux-of-guest /dev/mem-of-guest" in order to
> run live analysis of a guest.
> 
> Anyway, sorry if it doesn't meet your needs...
> 
> Dave
>