Description of problem: when restart 32bitwin23k which was assign more than 4G mem, qemu aborted. unhandled vm exit: 0x80000021 vcpu_id 2 rax 0000000000000000 rbx 0000000000000000 rcx 0000000000000000 rdx 0000000000000000 rsi 0000000000000000 rdi 0000000000000000 rsp 0000000000000000 rbp 0000000000000000 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 0000000000000000 rflags 00004002 cs 0000 (00000000/00000000 p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ds 0000 (00000000/00000000 p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) es 0000 (00000000/00000000 p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) ss 0000 (00000000/00000000 p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) fs 0000 (00000000/00000000 p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs 0000 (00000000/00000000 p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0058 (fffffffff773a350/00000068 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0000 (00000000/00000000 p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt f773d400/3ff idt f773d800/7ff cr0 8001003b cr2 d68b6020 cr3 7ac000 cr4 6b8 cr8 0 efer 800 Version-Release number of selected component (if applicable): 83-105 How reproducible: 100% Steps to Reproduce: 1.boot guest by: /usr/libexec/qemu-kvm -no-hpet -rtc-td-hack -drive file=win2003-32-virtio.qcow2,if=ide -cpu qemu64,+sse2 -m 4G -smp 4 -vnc :11& 2.restart guest. Actual results: Expected results: Additional info: This problem only happened in intel host.
host dmesg: set_cr3: #GP, pdptrs reserved bits set_cr3: #GP, pdptrs reserved bits kvm_handle_exit: unexpected, valid vectoring info (0x80000202) and exit reason is 0x80000021 kvm_handle_exit: unexpected, valid vectoring info (0x80000202) and exit reason is 0x80000021 set_cr3: #GP, pdptrs reserved bits set_cr3: #GP, pdptrs reserved bits kvm_handle_exit: unexpected, valid vectoring info (0x80000202) and exit reason is 0x80000021 kvm_handle_exit: unexpected, valid vectoring info (0x80000202) and exit reason is 0x80000021
Retest this bug: rhev-h-5.4-2.0.99.9 kvm-83-83 ==> Passed rhev-h-5.4-2.0.99.10.3 kvm-83-87 ==> Failed So, downgrade kvm to kvm-83-84 ==> Passed (kvm-83-85&86 packages are deleted in brewweb, so can not be test.) Please check. Thanks!
according to comment #2 setting Regression keyword.
Could you check if it is reproducible with the following options: (replacing the "-cpu qemu64,+sse2" option that you have used) 1) -cpu qemu64,model=2 2) -cpu qemu64,model=3 3) -cpu qemu64,model=6 Please also test if it can be reproduced using "-cpu qemu64,model=6" when using kvm-83-83.el5.
in kvm-83-106: /usr/libexec/qemu-kvm -no-hpet -rtc-td-hack -drive file=win23k-32-virtio.raw,if=ide -cpu qemu64,+sse2 -m 4G -smp 4 -net nic,macaddr=20:20:20:90:22:33,model=rtl8139,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -net nic,macaddr=20:20:20:90:22:32,model=virtio,vlan=1 -net tap,script=/etc/qemu-ifup,vlan=1 -net nic,macaddr=20:20:20:90:22:31,model=e1000,vlan=2 -net tap,script=/etc/qemu-ifup,vlan=2 -vnc :2 1) -cpu qemu64,model=2 : failed 2) -cpu qemu64,model=3 : pass 3) -cpu qemu64,model=6 : failed 4) -cpu qemu64,+sse2 : failed in kvm-83-83.el5 1) -cpu qemu64,model=2 : -Aborted 2) -cpu qemu64,model=3 : -pass 3) -cpu qemu64,model=6 : -Aborted 4) -cpu qemu64,+sse2 : -pass
Found the cause: the default was changed to model=6 by the fix for bug #508623.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Windows 2003 32-bit guests with more than 4GB of RAM may crash on reboot. This can be worked around by setting a different CPU model (model=3) on the management interface. [instructions to do this on RHEV-M are needed]
Could you test it with: "-cpu pentium3" also? If it works, we can mention the existing "pentium3" CPU model option on instructions to work around the bug (it would be a easier workaround than editing the cpu type raw configuration string on RHEV-M).
lihuang can you check if the failed tests also fails on svm systems? I guess not if it's because windows is trying to use big real mode on >4G reboot. What is insane is that it changes the reboot procedure depending on the cpu model... If svm works, other thing to test is "rmmod kvm-intel && modprobe kvm-intel emulate_invalid_guest_state=1". svm however might work for other reasons (I mean because of vendor_id flipped to amd which may invoked entirely different reboot procedure on windows)
(In reply to comment #9) > Could you test it with: "-cpu pentium3" also? > > If it works, we can mention the existing "pentium3" CPU model option on > instructions to work around the bug (it would be a easier workaround than > editing the cpu type raw configuration string on RHEV-M). Yes. restart is ok with "-cpu pentium3" parameter.
(In reply to comment #11) > (In reply to comment #9) > > Could you test it with: "-cpu pentium3" also? > > > > If it works, we can mention the existing "pentium3" CPU model option on > > instructions to work around the bug (it would be a easier workaround than > > editing the cpu type raw configuration string on RHEV-M). > > Yes. restart is ok with "-cpu pentium3" parameter. CLI: [root@dhcp-66-70-77 ~]# /usr/libexec/qemu-kvm -no-hpet -rtc-td-hack -drive file=/data/images/images/win2003-32-virtio.raw,if=ide -cpu pentium3 -m 4G -smp 4 -net nic,macaddr=20:20:20:90:22:33,model=rtl8139,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -net nic,macaddr=20:20:20:90:22:32,model=virtio,vlan=1 -net tap,script=/etc/qemu-ifup,vlan=1 -net nic,macaddr=20:20:20:90:22:31,model=e1000,vlan=2 -net tap,script=/etc/qemu-ifup,vlan=2 -vnc :2
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,3 +1,3 @@ -Windows 2003 32-bit guests with more than 4GB of RAM may crash on reboot. This can be worked around by setting a different CPU model (model=3) on the management interface. +Windows 2003 32-bit guests with more than 4GB of RAM may crash on reboot with the default qemu-kvm CPU settings. -[instructions to do this on RHEV-M are needed]+This can be worked around by configuring a different CPU model on the management interface. On RHEV-M, the "pentium3" CPU type can be used for that.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,3 +1 @@ -Windows 2003 32-bit guests with more than 4GB of RAM may crash on reboot with the default qemu-kvm CPU settings. +Windows 2003 32-bit guests with more than 4GB of RAM may crash on reboot with the default qemu-kvm CPU settings. To work around this issue, configure a different CPU model on the management interface.- -This can be worked around by configuring a different CPU model on the management interface. On RHEV-M, the "pentium3" CPU type can be used for that.
> lihuang can you check if the failed tests also fails on svm systems? I guess > not if it's because windows is trying to use big real mode on >4G reboot. What > is > insane is that it changes the reboot procedure depending on the cpu model... > test with kvm-83-106.el5 in svm system: 1) -cpu qemu64,model=2 : -pass 2) -cpu qemu64,model=3 : -pass 3) -cpu qemu64,model=6 : -pass 4) -cpu qemu64,+sse2 : -pass > If svm works, other thing to test is "rmmod kvm-intel && modprobe kvm-intel > emulate_invalid_guest_state=1". test in intel host and do "rmmod kvm-intel && insmod kvm-intel.ko emulate_invalid_guest_state=1" Found that vm cannot boot up and in host dmesg: printk: 2625858 messages suppressed. emulation failed (emulation failure) rip e433a f7 75 b4 83 > > svm however might work for other reasons (I mean because of vendor_id flipped > to amd which may invoked entirely different reboot procedure on windows)
(In reply to comment #17) > > lihuang can you check if the failed tests also fails on svm systems? I guess > > not if it's because windows is trying to use big real mode on >4G reboot. What > > is > > insane is that it changes the reboot procedure depending on the cpu model... > > > > test with kvm-83-106.el5 in svm system: > 1) -cpu qemu64,model=2 : -pass > 2) -cpu qemu64,model=3 : -pass > 3) -cpu qemu64,model=6 : -pass > 4) -cpu qemu64,+sse2 : -pass > > Can we close the bug than?
(In reply to comment #18) > (In reply to comment #17) > > > lihuang can you check if the failed tests also fails on svm systems? I guess > > > not if it's because windows is trying to use big real mode on >4G reboot. What > > > is > > > insane is that it changes the reboot procedure depending on the cpu model... > > > > > > > test with kvm-83-106.el5 in svm system: > > 1) -cpu qemu64,model=2 : -pass > > 2) -cpu qemu64,model=3 : -pass > > 3) -cpu qemu64,model=6 : -pass > > 4) -cpu qemu64,+sse2 : -pass > > > > > > Can we close the bug than? No, this problem still exists in Intel host. What i mean above is that it passes in AMD host. So Dor, can you change status to "New"?
So there are no instructions for doing this on RHEV M? Chris
in kvm-83-130.el5 1) -cpu qemu64,model=2 : -pass 2) -cpu qemu64,model=3 : -pass 3) -cpu qemu64,model=6 : -pass 4) -cpu qemu64,+sse2 : -pass 5) -cpu pentium3 : -pass cmd: /usr/libexec/qemu-kvm -no-hpet -rtc-td-hack -drive file=win2003-32.qcow2,if=ide -cpu qemu64,+sse2 -m 4G -smp 4 -net nic,macaddr=20:20:20:90:22:33,model=rtl8139,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -net nic,macaddr=20:20:20:90:22:32,model=virtio,vlan=1 -net tap,script=/etc/qemu-ifup,vlan=1 -vnc :2 -monitor stdio
Tested in kvm-83-139.el5 1) -cpu qemu64,model=2 : -pass 2) -cpu qemu64,model=3 : -pass 3) -cpu qemu64,model=6 : -pass 4) -cpu qemu64,+sse2 : -pass 5) -cpu pentium3 : -pass Could not find this bug on kvm-83-139.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0271.html
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days