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

[Paolo Bonzini]

On 24/06/2015 12:21, Michael S. Tsirkin wrote:
> > 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.

Same here, and I would be quite surprised of seeing any.  Except perhaps
when we introduced x2apic: that would have broken kernels <2.6.32, but I
hope we can ignore those.

At least as far as I've maintained KVM, we've not added new models to
QEMU after KVM's kernel support was added.

The only case I can imagine is that the kernel is ancient so it doesn't
have anything newer than say IvyBridge, while QEMU is new.  If the user
starts a Haswell VM on a SandyBridge host without "enforce", you will
have a problem when you reboot and get a newer kernel, but this is
independent of machine types.

We have added new features in exactly three cases:

1) F16 and RDRAND to {Haswell,Broadwell} in 2.3;

2) MOVBE to n270 in 1.5;

3) PCLMULQDQ to Westmere also in 1.5.

In all three cases, libvirt is still buggy and doesn't let you use the
features if you have the appropriate host.

We were close to breaking libvirt's expectations when we wanted to
remove TSX from Haswell/Broadwell, but in the end we did it right by
adding separate CPU models and no final release broke libvirt.

So, what is the broken case?  And BTW, what is _exactly_ preventing
libvirt from using enforce for models other than qemu32/qemu64?

Paolo