From: Wen Congyang <we...@cn.fujitsu.com> Subject: Re: [RFC][PATCH 00/14 v7] introducing a new, dedicated memory dump mechanism Date: Thu, 01 Mar 2012 13:16:47 +0800
> At 03/01/2012 12:42 PM, HATAYAMA Daisuke Wrote: >> From: Wen Congyang <we...@cn.fujitsu.com> >> Subject: [RFC][PATCH 00/14 v7] introducing a new, dedicated memory dump >> mechanism >> Date: Thu, 01 Mar 2012 10:35:44 +0800 >> >>> Hi, all >>> >>> 'virsh dump' can not work when host pci device is used by guest. We have >>> discussed this issue here: >>> http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00736.html >>> >>> The last version is here: >>> http://lists.nongnu.org/archive/html/qemu-devel/2012-02/msg01007.html >>> >>> We have determined to introduce a new command dump to dump memory. The core >>> file's format can be elf. >>> >>> Note: >>> 1. The guest should be x86 or x86_64. The other arch is not supported now. >>> 2. If you use old gdb, gdb may crash. I use gdb-7.3.1, and it does not >>> crash. >> >> Does this say the thing caused by gdb versions with no Dwarf V3 >> support? If so, it's better to write that too explicitly here. > > I donot know why gdb crashed, and I cannot reproduce this problem now. > Sorry. I meant Dwarf4. Recent GCC emits binary with Dwarf4 in default, and older GDBs cannot handle them although I don't know this is the same as what you saw. >>> 3. If the OS is in the second kernel, gdb may not work well, and crash can >>> work by specifying '--machdep phys_addr=xxx' in the command line. The >>> reason is that the second kernel will update the page table, and we can >>> not get the page table for the first kernel. >>> 4. The cpu's state is stored in QEMU note. You neet to modify crash to use >>> it to calculate phys_base. >> >> Again, you still need to fix crash utility to recover the 1st kernel's >> first 640kB physical memory that has been reserved during switch from >> 1st kernel to 2nd kernel. > > It is another work, I will try to do it in the future. > Please. Thanks. HATAYAMA, Daisuke
