Bug 516762 - qemu aborted when restart 32bitwin23k with more than 4G mem in intel host.
Summary: qemu aborted when restart 32bitwin23k with more than 4G mem in intel host.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm
Version: 5.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Gleb Natapov
QA Contact: Lawrence Lim
URL:
Whiteboard:
Depends On:
Blocks: 5.4, TechnicalNotes 532043
TreeView+ depends on / blocked
 
Reported: 2009-08-11 12:43 UTC by Miya Chen
Modified: 2023-09-14 01:17 UTC (History)
13 users (show)

Fixed In Version: kvm-83-130.el5
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2010-03-30 07:53:35 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0271 0 normal SHIPPED_LIVE Important: kvm security, bug fix and enhancement update 2010-03-29 13:19:48 UTC

Description Miya Chen 2009-08-11 12:43:32 UTC
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.

Comment 1 Miya Chen 2009-08-11 12:53:00 UTC
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

Comment 2 Qunfang Zhang 2009-08-12 08:44:34 UTC
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!

Comment 3 lihuang 2009-08-12 12:54:50 UTC
according to comment #2 
setting Regression keyword.

Comment 5 Eduardo Habkost 2009-08-17 20:47:02 UTC
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.

Comment 6 lihuang 2009-08-18 07:54:23 UTC
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

Comment 7 Eduardo Habkost 2009-08-18 12:48:18 UTC
Found the cause: the default was changed to model=6 by the fix for bug #508623.

Comment 8 Eduardo Habkost 2009-08-18 13:03:33 UTC
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]

Comment 9 Eduardo Habkost 2009-08-18 13:16:35 UTC
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).

Comment 10 Andrea Arcangeli 2009-08-18 13:24:34 UTC
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)

Comment 11 lihuang 2009-08-18 16:24:43 UTC
(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.

Comment 12 lihuang 2009-08-18 16:25:38 UTC
(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

Comment 13 Eduardo Habkost 2009-08-18 17:36:08 UTC
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.

Comment 16 Ryan Lerch 2009-08-19 03:31:43 UTC
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.

Comment 17 Miya Chen 2009-08-19 03:52:01 UTC
> 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)

Comment 18 Dor Laor 2009-10-01 08:52:09 UTC
(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?

Comment 19 Miya Chen 2009-10-09 03:40:17 UTC
(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"?

Comment 20 Christopher Curran 2009-10-23 03:53:28 UTC
So there are no instructions for doing this on RHEV M?

Chris

Comment 25 Golita Yue 2009-10-27 05:39:29 UTC
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

Comment 28 Golita Yue 2009-12-23 08:04:50 UTC
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

Comment 31 errata-xmlrpc 2010-03-30 07:53:35 UTC
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

Comment 32 Red Hat Bugzilla 2023-09-14 01:17:41 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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