From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG581-00084q-FP for qemu-devel@nongnu.org; Tue, 18 Oct 2011 04:34:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RG57w-0002Mj-NP for qemu-devel@nongnu.org; Tue, 18 Oct 2011 04:34:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG57w-0002L1-6r for qemu-devel@nongnu.org; Tue, 18 Oct 2011 04:34:24 -0400 Date: Tue, 18 Oct 2011 09:34:16 +0100 From: "Richard W.M. Jones" Message-ID: <20111018083416.GL8872@amd.home.annexia.org> References: <20111010090246.GF9408@redhat.com> <4E92BC11.3030508@siemens.com> <4E9D2791.5070207@cn.fujitsu.com> <4E9D3059.7050903@siemens.com> <4E9D31B4.1010000@cn.fujitsu.com> <4E9D3678.3010904@siemens.com> <4E9D3804.5040000@cn.fujitsu.com> <4E9D3847.8040202@siemens.com> <4E9D3965.4090003@cn.fujitsu.com> <4E9D394E.6050907@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9D394E.6050907@siemens.com> Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Luiz Capitulino On Tue, Oct 18, 2011 at 10:31:10AM +0200, Jan Kiszka 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? Crash can decode kernel structures, providing for example process listings and debugging into userspace processes. Crash actually reuses gdb's code too, so it's kind of a superset. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora