Bug 516762

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