From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60217)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1V9Hmc-0003v7-Dw
	for qemu-devel@nongnu.org; Tue, 13 Aug 2013 12:49:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1V9HmX-0000cR-DW
	for qemu-devel@nongnu.org; Tue, 13 Aug 2013 12:49:22 -0400
Received: from mx1.redhat.com ([209.132.183.28]:40082)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1V9HmX-0000c9-6B
	for qemu-devel@nongnu.org; Tue, 13 Aug 2013 12:49:17 -0400
Message-ID: <520A641F.5040608@redhat.com>
Date: Tue, 13 Aug 2013 18:51:43 +0200
From: Laszlo Ersek <lersek@redhat.com>
MIME-Version: 1.0
References: <CADLDEKvEVSXQeKKrU0Ke9cgMf2VBr=ooTmXrUgmb3C+XEmsSmA@mail.gmail.com>
	<520A58CD.9000404@suse.de>
In-Reply-To: <520A58CD.9000404@suse.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] QEMU savevm RAM page offsets
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: =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>, Juerg Haefliger <juergh@gmail.com>
Cc: qemu-devel@nongnu.org

On 08/13/13 18:03, Andreas F=E4rber wrote:
> Hi,
>=20
> Am 13.08.2013 15:30, schrieb Juerg Haefliger:
>> I'm writing/extending a little tool (courtesy of Andrew @pikewerks)
>> that dumps the RAM pages from a savevm file to a raw memory dump file
>> so that it can be analysed using tools that require a raw dump as
>> input.
>=20
> Can't you just use QEMU's guest-memory-dump API? Either directly or
> after loadvm'ing it.

That used to suffer from the exact same problem Juerg described, but I
fixed it for 1.6.

See the series at

  http://thread.gmane.org/gmane.comp.emulators.qemu/226715

(See patch 4/4 for a diagram that has been called "nice" in a private
email.)

Commit hashes:

1  2cac260 dump: clamp guest-provided mapping lengths to ramblock sizes
2  5ee163e dump: introduce GuestPhysBlockList
3  c5d7f60 dump: populate guest_phys_blocks
4  56c4bfb dump: rebase from host-private RAMBlock offsets to
           guest-physical addresses

(Red Hat BZ: <https://bugzilla.redhat.com/show_bug.cgi?id=3D981582>.)

In short, you have to use guest-physical addresses (hwaddr) instead of
qemu-internal RAMBlock offsets (ram_addr_t), because the vmcore analysis
tool ("crash" eg.) works with guest-phys addresses as well.

See also the HACKING file, section "2.1. Scalars".

So yes, use the dump-guest-memory QMP/HMP command.

Laszlo