warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

Bug #1722074 reported by htmldeveloper@gmail.com
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
QEMU
Invalid
Undecided
Unassigned
qemu (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

I encountered the bug today (when using qemu to boot up images - which used to work on my Intel CPU box):

warning: host doesn't support requested feature: CPUID.01H:ECX.vmx

The bug is a show-stopper - I completely cannot load my kernel images at all.

My Ubuntu have this version of QEMU installed:

qemu-system-x86_64 --version

QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2003-2008 Fabrice Bellard

And PC is a AMD Ryzen7 CPU built, and this is the first time I am using it to load QEMU images. My host information:

cat /proc/cpuinfo |more

processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 1
model name : AMD Ryzen 7 1700X Eight-Core Processor
stepping : 1
microcode : 0x800110e
cpu MHz : 2200.000
cache size : 512 KB
physical id : 0
siblings : 16
core id : 0
cpu cores : 8
apicid : 0
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 nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq
monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf
_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw s
kinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate
vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt
xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale v
mcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov
succor smca
bugs : fxsave_leak sysret_ss_attrs null_seg
bogomips : 6787.24
TLB size : 2560 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate eff_freq_ro [13] [14]

processor : 1
vendor_id : AuthenticAMD
cpu family : 23
model : 1
model name : AMD Ryzen 7 1700X Eight-Core Processor
stepping : 1
microcode : 0x800110e
cpu MHz : 2200.000
cache size : 512 KB

From other places, it can be seen that this is an AMD CPU issue:

https://www.virtualmin.com/node/52227

not sure?

The bug will also affect the host negatively: it will completely go into a hung mode - the entire host becomes completely unsable.

description: updated
Revision history for this message
Chris Kuethe (ckuethe) wrote :

Also reproducible
$ qemu-system-x86_64 --version
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.2)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
$ uname -a
Linux ryzen 4.16.11-041611-generic #201805221331 SMP Tue May 22 17:34:25 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ head -28 /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 8
model name : AMD Ryzen 7 2700X Eight-Core Processor
stepping : 2
microcode : 0x8008204
cpu MHz : 2161.008
cache size : 512 KB
physical id : 0
siblings : 16
core id : 0
cpu cores : 8
apicid : 0
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 nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
bugs : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips : 7399.25
TLB size : 2560 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 43 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate eff_freq_ro [13] [14]

Changed in qemu:
status: New → Incomplete
status: Incomplete → Opinion
status: Opinion → Invalid
Changed in qemu (Ubuntu):
status: New → Incomplete
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
this is not a show stopper at all.
It is just a warning and it is fine.
It is a trade-off between the "ease to use nested virt" vs "this warning".
For example on an intel chip you'd get:
  qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm
And that as well is no issue.

Since this is Ubuntu downstream decision to prefer simplicity for nested virt I marked upstream qemu task invalid. There you'd not see the warning, but instead would have to jump a few extra whoops to get nesting working.

And finally, this code really is like that for longer than I take a look at it, so it might be that today one could solve it differently. There could be much more magic code to make it work as comfortable on both platforms and avoid the warning, but honestly - it wasn't an issue for many years, and I think it still is none.
So for the Ubuntu portion, I'll set confirmed+low(est) prio until it is clear that this really breaks something it didn't in the past years.

Changed in qemu (Ubuntu):
status: Incomplete → Confirmed
importance: Undecided → Wishlist
importance: Wishlist → Low
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

And sorry for the status update noise, one can clearly see that I start to fail once I have to use my mouse :-)

Revision history for this message
Ken Sharp (kennybobs) wrote :

How is this a bug?

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
Ken - I think all I said in comment #2 still applies (and likely won't change).

It really is a non-issue warning - and even if you e.g. have a zero-warning-allowed policy then you can easily avoid that by using a CPU type that doesn't enable it by default or switch it on/off as needed. In libvirt that would be via CPU features [1] and in qemu via +/- flags on the -cpu switch. Like [2] but for vmx/svm flags.

Note that:
 $ qemu-system-x86_64 -cpu help
will show you all the types and features known to your current qemu.

[1]: https://libvirt.org/formatdomain.html#elementsCPU
[2]: https://www.berrange.com/posts/2018/06/29/cpu-model-configuration-for-qemu-kvm-on-x86-hosts/

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.