From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG50m-0002Io-QB for qemu-devel@nongnu.org; Tue, 18 Oct 2011 04:27:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RG50g-0000Gj-6o for qemu-devel@nongnu.org; Tue, 18 Oct 2011 04:27:00 -0400 Received: from david.siemens.de ([192.35.17.14]:34298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG50f-0000EM-S7 for qemu-devel@nongnu.org; Tue, 18 Oct 2011 04:26:54 -0400 Message-ID: <4E9D3847.8040202@siemens.com> Date: Tue, 18 Oct 2011 10:26:47 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E8ECA91.8040409@cn.fujitsu.com> <4E8ED167.1000705@siemens.com> <20111008151622.GA17181@amd.home.annexia.org> <4E916035.5050906@web.de> <20111009102338.GN16799@amd.home.annexia.org> <4E92568E.2010507@cn.fujitsu.com> <4E929618.4040403@web.de> <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> In-Reply-To: <4E9D3804.5040000@cn.fujitsu.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Wen Congyang Cc: qemu-devel , "Richard W.M. Jones" , Luiz Capitulino 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux