Description: When creating a VM, a policy is applied to mask certain CPUID features. Right now it's black magic.
THe KVM stack has done an excellent job of making this human-useable, and understandable.
For example, in a qemu-kvm command-line you may encounter:
-cpu SandyBridge,+pdpe1gb,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
And in <qemu>/target-i386.c you find a fairly comprehensive description of x86 processor models, what CPUID features are inherent, and what CPUID feature each of these symbolic flags enables.
In the Xen world, there is a libxc interface to do the same, although it's all hex and register driven. It's effective, yet horrible to use.
An ideal outcome would have libxl config files and command line absorb a similarly human-friendly description of the CPUID features a user wishes for the VM, and interface appropriately with libxl. Further, autodetection of best CPUID shuold yield a human-readable output to be able to easily understand what the VM thinks about its processor.
Finally, interfacing with libvirt should be carefully considered.
CPUID management is crucial in a heterogeneous cluster where migrations and save restore require careful processor feature selection to avoid blow-ups. |