qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: KAMEZAWA Hiroyuki
Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
Date: Wed, 19 Oct 2011 11:04:01 +0900

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.

Thanks,
-Kame
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]