Re: [Qemu-devel] [PATCH 0/4] dump-guest-memory: correct the vmcores

[Luiz Capitulino]

On Mon, 29 Jul 2013 16:37:12 +0200
Laszlo Ersek <address@hidden> wrote:

> (Apologies for the long To: list, I'm including everyone who
> participated in
> <https://lists.gnu.org/archive/html/qemu-devel/2012-09/msg02607.html>).
> 
> 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).

Applied to the qmp branch, thanks.

> 
> Please refer to Red Hat Bugzilla 981582
> <https://bugzilla.redhat.com/show_bug.cgi?id=981582>.
> 
> Disclaimer: as you can tell from my progress in the RHBZ, I'm new to the
> memory API. The way I'm using it might be retarded.
> 
> 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 ++-
>  6 files changed, 300 insertions(+), 92 deletions(-)
>