One way to do this would be to read QB_CPU from the env if it is set. Why would anyone want to do this? For x86-64 kvm situations, esp those involving nested qemu's you may need to set "-cpu host" in order to get certain cpu capabilities into the qemu env (vmx,sse_4_2,...).
punting this to 2.6
Brian, Tim: While this is an obvious convenience, I wanted to confirm that if this feature is still worth implementing and understand what's asked for. In runqemu, we see following environment variables are used: KERNEL - the kernel image file to use BIOS - the bios image file to use ROOTFS - the rootfs image file or nfsroot directory to use DEVICE_TREE - the device tree blob to use MACHINE - the machine name (optional, autodetected from KERNEL filename if unspecified) This feature asks to add QB_CPU to the list and used by runqemu [qb_cpu], however that option can easily be passed to runqemu by: $ runqemu [options] qemuparams="-cpu <model>" To add to that, to enable -cpu host, one needs kvm on host and pass it as an option to runqemu, otherwise errors out with: runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: CPU model 'host' requires KVM This is fine, as an error, and users need to understand what they are doing.
Brian is not longer with Intel or connected to the project. When I had looked into this earlier, I was thinking it was something missing in QEMU. Meaning newer Intel processor instruction sets were somehow not being added. As I dug deeper I realized the deeper reality. I agree that a knowledgeable user can use qemuparams="-cpu Skylake" for instance and this only works if they are on a Skylake or better CPU with kvm. Or if they do not use kvm, it will be slower and emulated. That leads me to two conclusions: (1) This is more a matter of documentation and good examples (2) This might be difficult to implement as a feature that will not be brittle and prone to failure Ultimately, as useful as the "runqemu" wrapper is, it is a crutch. Developers should pay attention to what the command line is that is being generated and modify it to their own needs. Testing more advanced instructions sets, like AVX512, will require a bit more knowledge both at compile time and run time emulation. It would be great if some magical introspection could make this "just work", but...that's not an obvious path. But might be worth some further experimentation.
That said, I do think we need to review our settings, because I think we are using deprecated values.
https://www.qemu.org/docs/master/system/target-i386.html#recommendations-for-kvm-cpu-model-configuration-on-x86-hosts Preferred CPU models for Intel x86 hosts The following CPU models are preferred for use on Intel hosts. Administrators / applications are recommended to use the CPU model that matches the generation of the host CPUs in use. In a deployment with a mixture of host CPU models between machines, if live migration compatibility is required, use the newest CPU model that is compatible across all desired hosts. Cascadelake-Server, Cascadelake-Server-noTSX Intel Xeon Processor (Cascade Lake, 2019), with “stepping” levels 6 or 7 only. (The Cascade Lake Xeon processor with stepping 5 is vulnerable to MDS variants.) Skylake-Server, Skylake-Server-IBRS, Skylake-Server-IBRS-noTSX Intel Xeon Processor (Skylake, 2016) Skylake-Client, Skylake-Client-IBRS, Skylake-Client-noTSX-IBRS} Intel Core Processor (Skylake, 2015) Broadwell, Broadwell-IBRS, Broadwell-noTSX, Broadwell-noTSX-IBRS Intel Core Processor (Broadwell, 2014) Haswell, Haswell-IBRS, Haswell-noTSX, Haswell-noTSX-IBRS Intel Core Processor (Haswell, 2013) IvyBridge, IvyBridge-IBR Intel Xeon E3-12xx v2 (Ivy Bridge, 2012) SandyBridge, SandyBridge-IBRS Intel Xeon E312xx (Sandy Bridge, 2011) Westmere, Westmere-IBRS Westmere E56xx/L56xx/X56xx (Nehalem-C, 2010) Nehalem, Nehalem-IBRS Intel Core i7 9xx (Nehalem Class Core i7, 2008) Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2, 2007) Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2, 2006)
Whereas we set: QEMU_EXTRAOPTIONS_core2-64 = " -cpu core2duo" http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/tune-core2.inc#n31 And even with core-i7 tuning, we are on the now ancient Nehalem architecture (12 years ago!): QEMU_EXTRAOPTIONS_corei7-64 = " -cpu Nehalem,check=false" http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/tune-corei7.inc#n31
In particular, core2duo is deprecated (equivalent of Penryn, 13 years ago!): https://www.qemu.org/docs/master/system/qemu-cpu-models.html?highlight=core2#other-non-recommended-x86-cpus We should at least consider moving that to Nehalem or Westmere.
Tim, looking at all the information provided, I think this is an issue of good documentation/examples. I was able to boot Skylake-Server using qemu only (did not try with runqemu and I do not think it will be a problem), with and without kvm, with Intel(R) Core(TM) i7-8665U CPU as the host, but with warnings emitted. This does not seem like an issue and only affects performance in my opinion. Also, I was able to run Westmere and Nehalem, with and without kvm and without warnings, delta of one generation. That being said, we can and should update: QEMU_EXTRAOPTIONS_core2-64 = " -cpu core2duo" to QEMU_EXTRAOPTIONS_core2-64 = " -cpu Nehalem,check=false" which is a delta of one generation, and should be fine. For those who are trying to test specific cpu instruction sets, one can expect them to be knowledgeable enough to use runqemu (or just qemu itself) to get the desired result they want. I will work on the update.
A nice idea but not a high priority.
Bulk move from 4.99 or 0.00 to 5.99
Thanks Simone, can you provide a link to the commit?