Hide Forgot
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.
(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.
Just have a try, paging=false not hit this problem.