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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 24, 2015 at 11:20:50AM +0200, Jiri Denemark wrote:
> 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.

Are there really many examples like this?  Could someone supply some
examples? Eduardo gave examples of CPU changes across machine types
but I haven't seen examples where we would break runnability.

> 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.

And the reason, presumably, is because it's a hard problem to solve.
Why is it easier to solve at the libvirt level?

> 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

I'm fine with the change itself, it's useful e.g. for testing.

But how is it a solution for libvirt's problems?
What is libvirt going to do in the above cases?

-- 
MST