From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ua0J2-0006Id-OX for qemu-devel@nongnu.org; Wed, 08 May 2013 05:05:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ua0Ix-0001yS-RP for qemu-devel@nongnu.org; Wed, 08 May 2013 05:05:00 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:36084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ua0Ix-0001yE-CF for qemu-devel@nongnu.org; Wed, 08 May 2013 05:04:55 -0400 Received: from m4.gw.fujitsu.co.jp (unknown [10.0.50.74]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 79EBB3EE0AE for ; Wed, 8 May 2013 18:04:52 +0900 (JST) Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 6A3F245DE4E for ; Wed, 8 May 2013 18:04:52 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 437BB45DE51 for ; Wed, 8 May 2013 18:04:52 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 2F40F1DB8046 for ; Wed, 8 May 2013 18:04:52 +0900 (JST) Received: from m1000.s.css.fujitsu.com (m1000.s.css.fujitsu.com [10.240.81.136]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 4B9381DB8041 for ; Wed, 8 May 2013 18:04:51 +0900 (JST) Message-ID: <518A14FA.1040307@jp.fujitsu.com> Date: Wed, 08 May 2013 18:03:54 +0900 From: HATAYAMA Daisuke MIME-Version: 1.0 References: <1367911007-13990-1-git-send-email-qiaonuohan@cn.fujitsu.com> In-Reply-To: <1367911007-13990-1-git-send-email-qiaonuohan@cn.fujitsu.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/9] Make monitor command 'dump-guest-memory' dump in kdump-compressed format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Qiao Nuohan Cc: qemu-devel@nongnu.org Please add CC list to Kumagai-san, makedumpfile maintainer, and Dave Anderson in order to let them know this development. (2013/05/07 16:16), Qiao Nuohan wrote: > Hi, all > > Command 'dump-guest-memory' was introduced to dump guest's memory. But the > vmcore's format is only elf32 or elf64. The message is here: > http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03379.html > > These patches are used to make 'dump-guest-memory' be able to dump guest's > memory in kdump-compressed format. Then vmcore can be much smaller, and > easily be delivered. > It should be stressed here that compression feature is *regression*. > Note, similar to 'dump-guest-memory': > 1. The guest should be x86 or x86_64. The other arch is not supported now. > 2. 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. > 3. The cpu's state is stored in QEMU note. > 4. The vmcore are able to be compressed with zlib, lzo or snappy. zlib is > available by default, and option '--enable-lzo' or '--enable-snappy' > should be used with configure to make lzo or snappy available. > > the kdump-compressed format is: Rather than detail of format, qemu people should want to know more general information about kdump-compressed format. They should think "What this format?" now. At least the following is needed: the kdump-compressed format is *linux specific* *linux standard* crash dump format used in kdump framework. > File offset > +------------------------------------------+ 0x0 > | main header (struct disk_dump_header) | > |------------------------------------------+ block 1 > | sub header (struct kdump_sub_header) | > |------------------------------------------+ block 2 > | 1st-dump_bitmap | > |------------------------------------------+ block 2 + X blocks > | 2nd-dump_bitmap | (aligned by block) > |------------------------------------------+ block 2 + 2 * X blocks > | page desc for pfn 0 (struct page_desc) | (aligned by block) > | page desc for pfn 1 (struct page_desc) | > | : | > | page desc for pfn Z (struct page_desc) | > |------------------------------------------| (not aligned by block) > | page data (pfn 0) | > | page data (pfn 1) | > | : | > | page data (pfn Z) | > +------------------------------------------+ offset_eraseinfo > | : | > +------------------------------------------+ Layout itself is important information. Not only describing this here, it's better to put it anywhere of source code or point at IMPLEMENTATION file in makedumpfile which describes orignal spec. -- Thanks. HATAYAMA, Daisuke