RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1122843 - Failed to dump win2012r2 guest memory by dump-guest-memory
Summary: Failed to dump win2012r2 guest memory by dump-guest-memory
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Laszlo Ersek
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2014-07-24 14:00:19 UTC
Target Upstream Version:
Embargoed:

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):

Host:
qemu-kvm-0.12.1.2-2.430.el6.x86_64
gpxe-roms-qemu-0.9.7-6.11.el6.noarch
qemu-kvm-debuginfo-0.12.1.2-2.430.el6.x86_64
qemu-img-0.12.1.2-2.430.el6.x86_64
qemu-kvm-tools-0.12.1.2-2.430.el6.x86_64
kernel-2.6.32-492.el6.x86_64

Guest:
windows server 2012r2

How reproducible:
always

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-0.12.1.2-2.430.el6)"}, "capabilities": []}}
{"execute":"qmp_capabilities"}
{"return": {}}
 {"execute":"dump-guest-memory","arguments":{"paging":true,"protocol":"file:/home/dump0"}}
{"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

3.

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
above).

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.