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

[Jiri Denemark <jdenemar@redhat.com>]

On Tue, Jun 23, 2015 at 14:32:00 +0200, Andreas Färber wrote:
> Am 08.06.2015 um 22:18 schrieb Jiri Denemark:
> >> 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.
> > 
> > Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU
> > configuration data to libvirt, but now I think it actually makes sense.
> > We already have a partial copy of CPU model definitions in libvirt
> > anyway, but as QEMU changes some CPU models in some machine types (and
> > libvirt does not do that) we have no real control over the guest CPU
> > configuration. While what we really want is full control to enforce
> > stable guest ABI.
> 
> That sounds like FUD to me. Any concrete data points where QEMU does not
> have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machines
> for.

QEMU provides stable ABI for x86 CPUs only if you use -cpu ...,enforce.
Without enforce the CPU may change everytime a domain is started or
migrated. A small example: let's say a CPU model called "Model" includes
feature "xyz"; when QEMU is started with -cpu Model (no enforce) on a
host which supports xyz, the guest OS will see a CPU with xyz, but when
you migrate it to a host which does not support xyz, QEMU will just
silently drop xyz. In other words, we need to use enforce to make sure
CPU ABI does not change.

But the problem is we can't use enforce because we don't know how a
specific CPU model looks like for a given machine type. Remember, while
libvirt allows users to explicitly ask for a specific CPU model and
features, it also has a mode when libvirt itself computes the right CPU
model and features. And this is impossible with enforce without us
knowing all details about CPU models.

So there are two possible ways to address this:
1. enhance QEMU to give us all we need
    - either by providing commands that would do all the computations
      (CPU model comparison, intersections or denominator, something
      like -cpu best)
    - or provide a way to probe for all (currently 700+) combinations of
      a CPU model and a machine type without actually having to start
      QEMU with each CPU and a machine type separately

2. manage CPU models in libvirt (aka -cpu custom)

During the past several years Eduardo tried to do (1) without getting
anywhere close to something that QEMU would be willing to accept. On the
other hand (2) is a pretty minimal change to QEMU and is more flexible
than (1) because it allows CPU model versions to be decoupled from
machine types (but this was already discussed a lot in the other emails
in this thread).

Jirka