The problem: The existing libvirt APIs assume that if a given CPU model is runnable in a host kernel+hardware combination, it will be always runnable on that host even if the machine-type changes.
That assumption is implied in some of libvirt interfaces, for example, at: 1) Host capabilities, which let callers know the set of CPU models that can run in a host: https://libvirt.org/formatcaps.html#elementHost "virsh capabilities" returns a CPU model name + CPU feature list, assuming that a CPU model name has a meaning that's independent from the machine-type. 2) The function that checks if a given CPU model definition is compatible with a host (virConnectCompareCPU()), which does not take the machine-type as argument: http://libvirt.org/html/libvirt-libvirt-host.html#virConnectCompareCPU But that assumption is not true, as QEMU changes CPU models in new machine-types when fixing bugs, or when new features (previously unsupported by QEMU, TCG or KVM) get implemented. The solution: libvirt can solve this problem partially by making sure every feature in a CPU model is explicitly configured, instead of (incorrectly) expecting that a named CPU model will never change in QEMU. But this doesn't solve the problem completely, because it is still possible that new features unknown to libvirt get enabled in the default CPU model in future machine-types (that's very likely to happen when we introduce new KVM features, for example). So, to make sure no new feature will be ever enabled without the knowledge of libvirt, add a "-cpu custom" mode, where no CPU model data is loaded at all, and everything needs to be configured explicitly using CPU properties. That means no CPU features will ever change depending on machine-type or accelerator capabilities when using "-cpu custom". * * * I know that this is basically the opposite of what we were aiming at in the last few month^Wyears, where we were struggling to implement probing interfaces to expose machine-type-dependent data for libvirt. But, at least the fact that we could implement the new approach using a 9-line patch means we were still going in the right direction. :) To help libvirt in the transition, a x86-cpu-model-dump script is provided, that will generate a config file that can be loaded using -readconfig, based on the -cpu and -machine options provided in the command-line. * * * This is basically the same version I sent as an RFC in April. A git tree is available at: git://github.com/ehabkost/qemu-hacks.git work/x86-cpu-custom-model Eduardo Habkost (2): target-i386: Introduce "-cpu custom" scripts: x86-cpu-model-dump script scripts/x86-cpu-model-dump | 322 +++++++++++++++++++++++++++++++++++++++++++++ target-i386/cpu.c | 10 +- 2 files changed, 331 insertions(+), 1 deletion(-) create mode 100755 scripts/x86-cpu-model-dump -- 2.1.0
