Re: [PATCH 0/7] i386: Add `machine` parameter to query-cpu-definitions

[David Hildenbrand]

> > > For example
> > > -machine s390-virtio-ccw-3.1 -cpu z14 will not have the multiple epoch facility
> > > and
> > > -machine s390-virtio-ccw-4.0 -cpu z14 will have the multiple epoch facility.
> > > As migration does always require the tuple of machine and cpu this is save. I 
> > > fail
> > > to see what the benefit of an explicit z14-3.1 would be.
> >
> > AFAIKS the only real benefit of versioned CPU models is that you can add new
> > CPU model versions without new QEMU version.
>
> This is very important for backporting CPU security fixes to existing QEMU
> releases.

I'd say it's not really relevant for backporting per se. It's relevant 
for automatically enabling security fixes when not using the host model. 
That part I understand. Less likely to make mistakes when explicitly 
specifying CPU models.

I once was told that if a user actually specified an explicit CPU model 
in the libvirt XML ("haswell-whatever"), you should not go ahead and 
make any later changes to that model (guest ABI should not change when 
you update/restart the guest ...). So this only applies when creating 
new guests? Or will you change existing model definitions implicitly?

> > Then you can specify "-cpu z13-vX" or "-cpu z13 -cpuv X" (no idea how
> > versioned CPU model were implemented) on any QEMU machine. Which is the same
> > as telling your customer "please use z13,featX=on" in case you have a good
> > reason to not use the host model (along with baselining) but use an explicit
> > model.
> >
> > If you can change the default model of QEMU machines, you can automate this
> > process. I am pretty sure this is a corner case, though (e.g., IBRS).
> > Usually you have a new QEMU machine and can simply enable the new feature
> > from that point on.
>
> There are now 4 Haswell variants, only some of which are runnable
> on any given host, depending on what microcode the user has installed
> or what particular Haswell silicon SKU the user purchased. Given the
> frequency of new CPU flaws arrived since the first Meltdown/Spectre,
> this isn't a corner case, at least for the x86 world & Intel in
> particular. Other arches/vendors haven't been quite so badly affected
> in this way.

On s390x you can assume that such firmware/microcode updates will be on 
any machine after some time. That is a big difference to x86-64 AFAIK.

> If we tied each new Haswell variant to a machine type, then users would
> be blocked from consuming a new machine type depending on runnability of
> the CPU model. This is not at all desirable, as mgmt apps now have complex
> rules on what machine type they can use.

So you actually want different CPU variants, which you have already, 
just in a different form. (e.g., "haswell" will be mapped to 
"haswell-whatever", just differently via versions)

> When dealing with backporting patches for new CPU hardware flaws, the
> new CPU features are backported to many old QEMU versions. The new
> machine types are not backportable.

That part I understand.

> Both these called for making CPU versioning independant of machine
> type versioning.
>
> Essentially the goal with CPU versioning is that the user can request
> a bare "Haswell" and libvirt (or the mgmt app) will automatically
> expand this to the best Haswell version that the host is able to
> support with its CPUs / microcode / BIOS config combination.


So if I do a "-cpu haswell -M whatever-machine", as far as I understood 
reading this,  I get the "default CPU model alias for that QEMU machine" 
and *not* the "best Haswell version that the host is able to support".

Or does the default actually also depend on the current host?

--

Thanks,

David / dhildenb