From: Laszlo Ersek <lersek@redhat.com>
To: lcapitulino@redhat.com, qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH v2 for-qmp-1.6 0/4] dump-guest-memory: correct the vmcores
Date: Mon, 5 Aug 2013 10:19:45 +0200 [thread overview]
Message-ID: <1375690789-25212-1-git-send-email-lersek@redhat.com> (raw)
v1->v2 [Luiz]:
- fix up the cpu_get_dump_info() prototype in "target-s390x/arch_dump.c"
that has been introduced between my posting of v1 and Luiz's applying
it to qmp-1.6. (Patch #4.)
v1 blurb:
Conceptually, the dump-guest-memory command works as follows:
(a) pause the guest,
(b) get a snapshot of the guest's physical memory map, as provided by
qemu,
(c) retrieve the guest's virtual mappings, as seen by the guest (this is
where paging=true vs. paging=false makes a difference),
(d) filter (c) as requested by the QMP caller,
(e) write ELF headers, keying off (b) -- the guest's physmap -- and (d)
-- the filtered guest mappings.
(f) dump RAM contents, keying off the same (b) and (d),
(g) unpause the guest (if necessary).
Patch #1 affects step (e); specifically, how (d) is matched against (b),
when "paging" is "true", and the guest kernel maps more guest-physical
RAM than it actually has.
This can be done by non-malicious, clean-state guests (eg. a pristine
RHEL-6.4 guest), and may cause libbfd errors due to PT_LOAD entries
(coming directly from the guest page tables) exceeding the vmcore file's
size.
Patches #2 to #4 are independent of the "paging" option (or, more
precisely, affect them equally); they affect (b). Currently input
parameter (b), that is, the guest's physical memory map as provided by
qemu, is implicitly represented by "ram_list.blocks". As a result, steps
and outputs dependent on (b) will refer to qemu-internal offsets.
Unfortunately, this breaks when the guest-visible physical addresses
diverge from the qemu-internal, RAMBlock based representation. This can
happen eg. for guests > 3.5 GB, due to the 32-bit PCI hole; see patch #4
for a diagram.
Patch #2 introduces input parameter (b) explicitly, as a reasonably
minimal map of guest-physical address ranges. (Minimality is not a hard
requirement here, it just decreases the number of PT_LOAD entries
written to the vmcore header.) Patch #3 populates this map. Patch #4
rebases the dump-guest-memory command to it, so that steps (e) and (f)
work with guest-phys addresses.
As a result, the "crash" utility can parse vmcores dumped for big x86_64
guests (paging=false).
Please refer to Red Hat Bugzilla 981582
<https://bugzilla.redhat.com/show_bug.cgi?id=981582>.
Laszlo Ersek (4):
dump: clamp guest-provided mapping lengths to ramblock sizes
dump: introduce GuestPhysBlockList
dump: populate guest_phys_blocks
dump: rebase from host-private RAMBlock offsets to guest-physical
addresses
include/sysemu/dump.h | 4 +-
include/sysemu/memory_mapping.h | 30 ++++++-
dump.c | 171 +++++++++++++++++++++-----------------
memory_mapping.c | 174 +++++++++++++++++++++++++++++++++++++--
stubs/dump.c | 3 +-
target-i386/arch_dump.c | 10 ++-
target-s390x/arch_dump.c | 3 +-
7 files changed, 302 insertions(+), 93 deletions(-)
next reply other threads:[~2013-08-05 8:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 8:19 Laszlo Ersek [this message]
2013-08-05 8:19 ` [Qemu-devel] [PATCH v2 for-qmp-1.6 1/4] dump: clamp guest-provided mapping lengths to ramblock sizes Laszlo Ersek
2013-08-05 8:19 ` [Qemu-devel] [PATCH v2 for-qmp-1.6 2/4] dump: introduce GuestPhysBlockList Laszlo Ersek
2013-08-05 8:19 ` [Qemu-devel] [PATCH v2 for-qmp-1.6 3/4] dump: populate guest_phys_blocks Laszlo Ersek
2013-08-05 14:23 ` Paolo Bonzini
2013-08-05 8:19 ` [Qemu-devel] [PATCH v2 for-qmp-1.6 4/4] dump: rebase from host-private RAMBlock offsets to guest-physical addresses Laszlo Ersek
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=1375690789-25212-1-git-send-email-lersek@redhat.com \
--to=lersek@redhat.com \
--cc=lcapitulino@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).