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

[Dave Anderson]

----- 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...

Dave