qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [RFC 0/2] target-i386: "custom" CPU model + script to dump


From: Eduardo Habkost
Subject: [Qemu-devel] [RFC 0/2] target-i386: "custom" CPU model + script to dump existing CPU models
Date: Mon, 13 Apr 2015 17:57:26 -0300

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 series is based on my x86 tree, with the additional feature flag
properties patch. A git tree is available at:
  https://github.com/ehabkost/qemu-hacks.git work/cpu-model-dump-script

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]