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

[Jan Kiszka]

On 2011-10-21 15:02, Dave Anderson wrote:
> 
> 
> ----- 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
> 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...

Yes, I'd prefer to have the added value of crash available with standard
gdb, specifically to reuse it for remote target debugging which is
fairly common in embedded scenarios and for guest debugging (via
qemu/kvm). I do not yet see that there is anything preventing this
except that it "needs to be done" - or collected from previous work:
there should be, e.g., dozens of gdb scripts circling around that
automate kernel module symbol loading with gdb.

We do have a proper remote debugging interface already, no need to
invent a new one for crash-on-qemu. We do lack complete x86 system-level
debugging support, but that's an absolutely generic gdb problem,
independent of Linux as a debugging target. And, AFAIK, we do not have
such issues with common non-x86 targets.

Jan

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