Bug 1122843 - Failed to dump win2012r2 guest memory by dump-guest-memory
Summary: Failed to dump win2012r2 guest memory by dump-guest-memory
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Laszlo Ersek
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-24 08:22 UTC by mazhang
Modified: 2016-09-20 04:41 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-07-24 14:00:19 UTC

Attachments (Terms of Use)

Description mazhang 2014-07-24 08:22:47 UTC
Description of problem:
Dump win2012r2 guest memory failed by "dump-guest-memory" command, guest stoped, hmp monitor hang.

Version-Release number of selected component (if applicable):


windows server 2012r2

How reproducible:

Steps to Reproduce:
1.Boot guest
/usr/libexec/qemu-kvm \
-M rhel6.6.0 \
-cpu Opteron_G4 \
-m 4G \
-smp 4,sockets=2,cores=2,threads=1,maxcpus=160 \
-enable-kvm \
-name rhel6.6 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-rtc base=localtime,clock=host,driftfix=slew \
-nodefaults \
-monitor stdio \
-qmp tcp:0:6666,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-chardev socket,id=seabios,path=/tmp/seabios0,server,nowait \
-device isa-debugcon,chardev=seabios,iobase=0x402 \
-monitor unix:/tmp/socket0,server,nowait -device sga \
-vga qxl \
-spice port=5900,disable-ticketing \
-usb \
-device usb-tablet,id=tablet0 \
-drive file=/usr/share/virtio-win/virtio-win.iso,if=none,media=cdrom,id=drive-ide1,readonly=on,format=raw \
-device ide-drive,bus=ide.1,unit=0,drive=drive-ide1,id=ide1 \
-drive file=/home/win2012r2.raw,if=none,id=drive-virtio-disk0,format=raw,cache=none,werror=stop,rerror=stop,aio=threads \
-device virtio-blk-pci,scsi=off,bus=pci.0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
-netdev tap,id=hostnet0,fd=5,vhost=on \
-device virtio-net-pci,netdev=hostnet0,mac=96:79:1f:dd:0d:4b,id=net0 5<>/dev/tap9 \

2.Try dump guest memory.

{"QMP": {"version": {"qemu": {"micro": 1, "minor": 12, "major": 0}, "package": "(qemu-kvm-"}, "capabilities": []}}
{"return": {}}
{"timestamp": {"seconds": 1406189191, "microseconds": 92718}, "event": "STOP"}

[root@hp-dl385g7-13 ~]# ll /home/dump0 
-r--------. 1 root root 0 Jul 24 16:06 /home/dump0
[root@hp-dl385g7-13 ~]# ll /home/dump0 
-r--------. 1 root root 0 Jul 24 16:06 /home/dump0


Actual results:
Guest stop, hmp monitor hang, can not resume from stop after 10 minutes.

Expected results:
If this command not support windows guest, should prompt warning or can resume from stop.

Additional info:
win7-64 and rhel6.6-64 guest can't hit this problem.

Comment 2 Laszlo Ersek 2014-07-24 14:00:19 UTC
(In reply to mazhang from comment #0)

> {"execute":"dump-guest-memory","arguments":{"paging":true,
> "protocol":"file:/home/dump0"}}

The above QMP command requests paging. Two notes about that:

(1) in case of Linux guests, paging is only needed if you want to use "gdb"
    for vmcore analysis, rather than "crash". In downstream we only analyze
    RHEL guest vmcores with "crash", so paging for RHEL guests is never
    needed, or a good idea.

(2) The documentation of the dump-guest-memory QMP command has the following
    to say about a paging-enabled dump (see file "qapi-schema.json"):

# @paging: if true, do paging to get guest's memory mapping. This allows
#          using gdb to process the core file.
#          IMPORTANT: this option can make QEMU allocate several gigabytes
#                     of RAM. This can happen for a large guest, or a
#                     malicious guest pretending to be large.
#          Also, paging=true has the following limitations:
#             1. The guest may be in a catastrophic state or can have
#                corrupted memory, which cannot be trusted
#             2. The guest can be in real-mode even if paging is enabled. For
#                example, the guest uses ACPI to sleep, and ACPI sleep state
#                goes in real-mode

Basically, when you request paging=true, you tell QEMU (a *host* process) to
walk the page tables that the *guest* has set up. In other words, you ask
the host-side process to parse and interpret data configured by the guest.
If the guest's data (== its page tables) are corrupt, "malicious", or even
just "unusual", you can run into problems.

dump_init() [dump.c]
  qemu_get_guest_memory_mapping() [memory_mapping.c]
    cpu_get_memory_mapping() [target-i386/arch_memory_mapping.c]
      walk_pml4e() [target-i386/arch_memory_mapping.c]

The solution is simple, never specify paging=true.

> Expected results:
> If this command not support windows guest, should prompt warning or can
> resume from stop.

The dump code has no clue if the guest is windows or not, it just looks at
the paging-related registers and data structures (see the above quote

If necessary, this bug can be moved to virt-documentation, in order to
document this in a more visible manner.

Comment 3 mazhang 2014-07-25 07:45:13 UTC
Just have a try, paging=false not hit this problem.

Note You need to log in before you can comment on or make changes to this bug.