From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:34183)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1RG6BK-0007Sh-8L
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 05:41:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1RG6BG-0002Ry-20
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 05:41:58 -0400
Received: from [222.73.24.84] (port=63454 helo=song.cn.fujitsu.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1RG6B4-0002Qf-VX
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 05:41:54 -0400
Message-ID: <4E9D4A2D.1070907@cn.fujitsu.com>
Date: Tue, 18 Oct 2011 17:43:09 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
MIME-Version: 1.0
References: <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> <4E9D3847.8040202@siemens.com>
	<4E9D3965.4090003@cn.fujitsu.com> <4E9D394E.6050907@siemens.com>
	<20111018083416.GL8872@amd.home.annexia.org>
	<4E9D3A80.10402@siemens.com>
In-Reply-To: <4E9D3A80.10402@siemens.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is
 used by guest
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, "Richard W.M. Jones" <rjones@redhat.com>, Luiz Capitulino <lcapitulino@redhat.com>

At 10/18/2011 04:36 PM, Jan Kiszka Write:
> On 2011-10-18 10:34, Richard W.M. Jones wrote:
> 
> Yeah, I see. Could also be solved via gdb scripts, but crash is already
> there.
> 
> But let's see if the formats actually differ. In the end, crash is just
> parsing the same information that also gdb sees.

I think the format can be similar with diskdump/kdump/netdump:

dump_header:     1 block
sub header:      n blocks(n is stored in dump_header)
bitmap:          m blocks(2m is stored in dump_header)
dumpable bitmap: m blocks
memory data(We can know whether a page is stored in the core by bitmap and dumpable bitmap)

The format of dump header(It's like kdump/diskdump):
struct disk_dump_header {
	char			signature[SIG_LEN];	/* = "QEMU    " */
	int			header_version; /* Dump header version */
	struct new_utsname	utsname;	/* copy of system_utsname */
	struct timeval		timestamp;	/* Time stamp */
	unsigned int		status;
	int			block_size;	/* Size of a block in byte */
	int			sub_hdr_size;	/* Size of arch dependent
						   header in blocks */
	unsigned int		bitmap_blocks;	/* Size of Memory bitmap in
						   block */
	unsigned int		max_mapnr;	/* = max_mapnr */
	unsigned int		total_ram_blocks;/* Number of blocks should be
						   written */
	unsigned int		device_blocks;	/* Number of total blocks in
						 * the dump device */
	unsigned int		written_blocks; /* Number of written blocks */
	unsigned int		current_cpu;	/* CPU# which handles dump */
	int			nr_cpus;	/* Number of CPUs */
};

The sub header can contains all registers's value on each vcpu, and other information,
for example:
struct qemu_sub_header {
	unsigned long	start_pfn;
	unsigned long	end_pfn;
	off_t		offset_note;
	unsigned long	size_note;
};

Thanks
Wen Congyang

> 
> Jan
>