Ping? Any feedback? I want to get this into 2.4. On Mon, Jun 08, 2015 at 04:07:38PM -0300, Eduardo Habkost wrote: > 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 > >
-- Eduardo
