qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU savevm RAM page offsets


From: Laszlo Ersek
Subject: Re: [Qemu-devel] QEMU savevm RAM page offsets
Date: Tue, 13 Aug 2013 18:51:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130621 Thunderbird/17.0.7

On 08/13/13 18:03, Andreas Färber wrote:
> Hi,
> 
> 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.
> 
> 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=981582>.)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]