From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIbZr-0000Cm-0f for qemu-devel@nongnu.org; Tue, 25 Oct 2011 03:37:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIbZm-0005f2-Bw for qemu-devel@nongnu.org; Tue, 25 Oct 2011 03:37:38 -0400 Received: from thoth.sbs.de ([192.35.17.2]:24912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIbZm-0005eo-3N for qemu-devel@nongnu.org; Tue, 25 Oct 2011 03:37:34 -0400 Message-ID: <4EA6672B.4060305@siemens.com> Date: Tue, 25 Oct 2011 09:37:15 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4EA612C4.40409@cn.fujitsu.com> In-Reply-To: <4EA612C4.40409@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" , Dave Anderson , Avi Kivity , Luiz Capitulino , KAMEZAWA Hiroyuki On 2011-10-25 03:37, Wen Congyang wrote: > At 10/24/2011 11:58 PM, Dave Anderson Write: >> >> >> ----- Original Message ----- >> >>>>> No, an ELF image of the guest's physical memory. >>>> >>>> Well then that should be pretty straight forward to support. Depending upon >>>> how similar it would be to the "standard" kdump ELF format, the only other >>>> issue is how to determine the physical base address at which the kernel is >>>> loaded, in order to be able to translate the mapped kernel-text/static-data >>>> virtual region of the x86_64 arch (the __START_KERNEL_map region). >>>> >>> >>> I guess an elf note would work for that? >> >> Right -- here is an example of a RHEL6 ELF kdump header: > > Hi, Jan > Is gdb standard core file like the following format? Does gdb support this > format? > > If yes, I think the dump command can output the guest physical memory in > the following format, and we can use both gdb and crash to analyze it. That would be ideal. But given lacking crash-like add-ons for vanilla gdb, it makes sense to focus on crash compatibility for now. I suspect we will need some changes to gdb anyway to make use of all information the kdump file contains. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux