All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>,
	"Juerg Haefliger" <juergh@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEMU savevm RAM page offsets
Date: Tue, 13 Aug 2013 18:51:43 +0200	[thread overview]
Message-ID: <520A641F.5040608@redhat.com> (raw)
In-Reply-To: <520A58CD.9000404@suse.de>

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	other threads:[~2013-08-13 16:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-13 13:30 [Qemu-devel] QEMU savevm RAM page offsets Juerg Haefliger
2013-08-13 16:03 ` Andreas Färber
2013-08-13 16:51   ` Laszlo Ersek [this message]
2013-08-13 16:58     ` Laszlo Ersek
2013-08-13 17:52       ` Juerg Haefliger
2013-08-13 18:07         ` Paolo Bonzini
2013-08-13 19:06           ` Juerg Haefliger
2013-08-13 19:25             ` Laszlo Ersek
2013-08-16  6:12               ` Juerg Haefliger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=520A641F.5040608@redhat.com \
    --to=lersek@redhat.com \
    --cc=afaerber@suse.de \
    --cc=juergh@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.