Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models

[Eduardo Habkost]

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