From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3HRp-00086U-GR for qemu-devel@nongnu.org; Thu, 01 Mar 2012 20:38:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3HRm-0007V0-Ht for qemu-devel@nongnu.org; Thu, 01 Mar 2012 20:38:17 -0500 Received: from [222.73.24.84] (port=12728 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3HRm-0007Ui-6S for qemu-devel@nongnu.org; Thu, 01 Mar 2012 20:38:14 -0500 Message-ID: <4F5024D3.1050002@cn.fujitsu.com> Date: Fri, 02 Mar 2012 09:39:31 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F4EE080.9060307@cn.fujitsu.com> <20120301.134227.488336914.d.hatayama@jp.fujitsu.com> <4F4F063F.6090609@cn.fujitsu.com> <20120302.094955.193694867.d.hatayama@jp.fujitsu.com> In-Reply-To: <20120302.094955.193694867.d.hatayama@jp.fujitsu.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC][PATCH 00/14 v7] introducing a new, dedicated memory dump mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: HATAYAMA Daisuke Cc: jan.kiszka@siemens.com, anderson@redhat.com, qemu-devel@nongnu.org, eblake@redhat.com, lcapitulino@redhat.com At 03/02/2012 08:49 AM, HATAYAMA Daisuke Wrote: > From: Wen Congyang > 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 >>> 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. I guess it is not, as I cannot reproduce this problem. Thanks Wen Congyang > >>>> 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 > >