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 821581 - should fail to boot a guest with SandyBridge/Westmere/Nehalem/Penryn/Conroe model on the Opteron_G4 host
Summary: should fail to boot a guest with SandyBridge/Westmere/Nehalem/Penryn/Conroe m...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: pre-dev-freeze
: ---
Assignee: Eduardo Habkost
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 833129
TreeView+ depends on / blocked
 
Reported: 2012-05-15 02:21 UTC by Sibiao Luo
Modified: 2014-06-18 03:15 UTC (History)
18 users (show)

Fixed In Version: upstream qemu-1.4.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 11:16:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Sibiao Luo 2012-05-15 02:21:02 UTC 
Description of problem:
boot a guest with SandyBridge/Westmere/Nehalem/Penryn/Conroe model on the Opteron_G4 host successfully without any warning prompts. the Opteron_G4 host not support the SandyBridge/Westmere/Nehalem/Penryn/Conroe model, so it should failed to boot all the guest and the QEMU should give some warning prompts.

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-270.el6.x86_64
qemu-kvm-0.12.1.2-2.292.el6.x86_64
guest info:
guest name: RHEL6.3-20120509-x86_64
# uname -r
2.6.32-270.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot a guest with SandyBridge/Westmere/Nehalem/Penryn/Conroe model on Opteron_G4 host.
eg: # <qemu-kvm-cmd> -cpu SandyBridge,enforce ...
2.
3.
  
Actual results:
after the step 1, all the guest boot successfully without any warning prompts.

Expected results:
all the guest should failed to boot and the QEMU should give some warning prompts.

Additional info:
1.also boot a guest with Opteron_G4 model on the SandyBridge host, the result is that failed to boot the guest and the QEMU should give some warning prompts.
eg: # <qemu-kvm-cmd> -cpu Opteron_G4,enforce ...
the QEMU give some warning prompts as following:
warning: host cpuid 8000_0001:edx lacks requested flag 'mtrr' [0x00001000]
warning: host cpuid 8000_0001:edx lacks requested flag 'mca' [0x00004000]
warning: host cpuid 8000_0001:edx lacks requested flag 'pse36' [0x00020000]
warning: host cpuid 8000_0001:ecx lacks requested flag 'svm' [0x00000004]
warning: host cpuid 8000_0001:ecx lacks requested flag 'abm' [0x00000020]
warning: host cpuid 8000_0001:ecx lacks requested flag 'sse4a' [0x00000040]
warning: host cpuid 8000_0001:ecx lacks requested flag 'misalignsse' [0x00000080]
warning: host cpuid 8000_0001:ecx lacks requested flag '3dnowprefetch' [0x00000100]
warning: host cpuid 8000_0001:ecx lacks requested flag 'xop' [0x00000800]
warning: host cpuid 8000_0001:ecx lacks requested flag 'fma4' [0x00010000]
Unable to support requested x86 CPU definition

2.my AMD Opteron_G4 host info:
processor	: 5
vendor_id	: AuthenticAMD
cpu family	: 21
model		: 1
model name	: AMD FX(tm)-6100 Six-Core Processor             
stepping	: 2
cpu MHz		: 1400.000
cache size	: 2048 KB
physical id	: 0
siblings	: 6
core id		: 5
cpu cores	: 3
apicid		: 21
initial apicid	: 5
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core cpb npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips	: 6599.67
TLB size	: 1536 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb
Comment 1 juzhang 2012-05-15 03:19:26 UTC 
Not very sure this bug is duplicated to the following bug.
FYI
Bug 692374 - -cpu enforce with wrong cpu flags does not cause qemu-kvm process quit
Comment 2 Eduardo Habkost 2012-07-20 13:34:28 UTC 

*** This bug has been marked as a duplicate of bug 692374 ***
Comment 4 langfang 2012-11-07 09:58:10 UTC 
hit the same problem on Opteron_G5 host.Boot a guest with /Westmere/Nehalem/Penryn/Conroe model on the Opteron_G5 host ,guest can be successfully boot without any warning prompts. 

version:
# uname -r
2.6.32-339.el6.x86_64
# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.334.el6.x86_64
host:
# cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 21
model		: 2
model name	: AMD Eng Sample, 1S256146U8K54_35/25/20_2/8     
stepping	: 0
cpu MHz		: 1400.000
cache size	: 2048 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 16
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core cpb npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1
bogomips	: 4987.26
TLB size	: 1536 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

steps:
1.boot a guest with Westmere/Nehalem/Penryn/Conroe model on Opteron_G5 host.
eg: # <qemu-kvm-cmd> -cpu Westmere,enforce ...
2.
3.

results:
guest boot successfully , without any warning prompts

addinfo:but if boot guest with "-cpu SandyBridge,enforce" on Opteron_G5 host,will prompt: 

 #/usr/libexec/qemu-kvm ...... -serial unix:/tmp/tty0,server,nowait -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -usbdevice tablet
warning: host cpuid 0000_0001:ecx lacks requested flag 'tsc-deadline' [0x01000000]
Unable to support requested x86 CPU definition

--->then qemu quit
Comment 8 Eduardo Habkost 2013-02-28 16:16:58 UTC 
The -cpu enforce bugs should be fixed on QEMU 1.4.0, see bug 822616.

But please note that it is not true that the Intel models should always fail to start on AMD CPUs. If the features defined in a CPU model are a subset of the models available on the host, -cpu enforce won't abort. -cpu enforce doesn't check the CPU vendor at all, it just checks if all the requested features are supported by the host.
Comment 10 huiqingding 2014-01-24 02:30:40 UTC 
Verify this bug using the following version:
qemu-kvm-1.5.3-40.el7.x86_64
kernel-3.10.0-64.el7.x86_64


Steps of verification:
1. boot a SandyBridge guest on Opteron_G5 host
# /usr/libexec/qemu-kvm -M pc -cpu SandyBridge,enforce ...
2. boot a Westmere guest on Opteron_G5 host
# /usr/libexec/qemu-kvm -M pc -cpu Westmere,enforce ...
3. 1. boot a Nehalem guest on Opteron_G5 host
# /usr/libexec/qemu-kvm -M pc -cpu Nehalem,enforce ...
4. 1. boot a Penryn guest on Opteron_G5 host
# /usr/libexec/qemu-kvm -M pc -cpu Penryn,enforce ...
5. 1. boot a Conroe guest on Opteron_G5 host
# /usr/libexec/qemu-kvm -M pc -cpu Conroe,enforce ...

Actual results:
1. After step1, SandyBrdige guest cannot boot and qemu-kvm quits with the error info:
(qemu) warning: host doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27]
qemu-kvm: Host's CPU doesn't support requested features

2. After step2, 3, 4, 5, Westmere/Nehalem/Penryn/Conroe guest can boot.
Comment 11 huiqingding 2014-01-24 02:34:42 UTC 
Hi, Eduardo,

I have a question, Westmere and SandyBrdige models have a flag "x2apic" and I check "/proc/cpuinfo" of Opteron_G5 host, there is not "x2apic". Why Westmere guest can boot on Opteron_G5 host, and not checking this flag "x2apic"?

Look forward to your answer, thanks a lot.

Best regards
Huiqing
Comment 12 Eduardo Habkost 2014-01-24 13:09:33 UTC 
x2apic is emulated by KVM, it doesn't require host CPU support.

qemu-kvm should only abort if there is any feature on the CPU model that can't be supported by the host. qemu-kvm doesn't care about the CPU vendor ID at all. See comment #8.

Opteron_G5 hosts seem to have all the features required by Westmere, Nehalem, Penryn, and Conroe, so it is not aborting.
Comment 14 Ludek Smid 2014-06-13 11:16:51 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.