Re: [Qemu-devel] CPU model versioning separate from machine type versioning ?

[Eduardo Habkost]

On Thu, Jun 28, 2018 at 04:45:02PM +0100, Daniel P. Berrangé wrote:
[...]
> What if we can borrow the concept of versioning from machine types and apply
> it to CPU models directly. For example, considering the history of "Haswell"
> in QEMU, if we had versioned things, we would by now have:
> 
>      Haswell-1.3.0 - first version (37507094f350b75c62dc059f998e7185de3ab60a)
>      Haswell-2.2.0 - added 'rdrand' (78a611f1936b3eac8ed78a2be2146a742a85212c_
>      Haswell-2.3.0 - removed 'hle' & 'rtm' 
> (a356850b80b3d13b2ef737dad2acb05e6da03753)
>      Haswell-2.5.0 - added 'abm' (becb66673ec30cb604926d247ab9449a60ad8b11
>      Haswell-2.12.0 - added 'spec-ctrl' 
> (ac96c41354b7e4c70b756342d9b686e31ab87458)
>      Haswell-3.0.0  - added 'ssbd' (never done)
> 
> If we followed the machine type approach, then a bare "Haswell" would
> statically resolve at build time to the most recent Haswell-X.X.X version
> associated with the QEMU release. This is unhelpful as we have a direct
> dependancy on the host hardware features. Better would be for a bare
> "Haswell" to be dynamically resolved at runtime, picking the most recent
> version that is capable of launching given the current hardware, KVM/TCG impl
> and QEMU version.
> 
>   ie -cpu  Haswell
> 
> should use Haswell-2.5.0  if on silicon with the TSX errata applied,
> but use Haswell-2.12.0 if the Spectre errata is applied in microcode,
> and use Haswell-3.0.0 once Intel finally releases SSBD microcode errata.

Doing this unconditionally would make
"-machine pc-q35-3.1 -cpu Haswell" unsafe for live migration, and
break existing usage.  But this behavior could be enabled
explicitly somehow.

> 
> Versioning of CPU models as opposed to using arbitrary string suffixes
> (-noTSX, -IBRS) has a number of usability improvements that we would
> gain with versioned machine types, while avoiding exploding the machine
> type matrix. With versioned CPU models we can
> 
>  - Automatically tailor the best model based on hardware support
> 
>  - Users always get the best model if they use the bare CPU name
> 
>  - It is obvious to users which is the "best" / "newest" CPU model
> 
>  - Avoid combinatorial expansion of machines since same CPU model
>    version can be added to all releases without adding machine types.
> 
>  - Users can still force a specific downgraded model by using the
>    fully versioned name.
> 
> Such versioning of CPU models would largely "just work" with existing
> libvirt versions, but to libvirt would really want to expand the bare
> CPU name to a versioned CPU name when recording new guest XML, so the
> ABI is preserved long term.
> 
> An application like virt-manager which wants a simple UI can forever be
> happy simply giving users a list of bare CPU model names, and allowing
> libvirt / QEMU to automatically expand to the best versioned model for
> their host.
> 
> An application like oVirt/OpenStack which wants direct control can allow
> the admin to choice if a bare name, or explicitly picking a versioned name
> if they need to cope with possibility of outdated hosts.
> 

The proposal makes sense, and I think most of it can be already
implemented on top of existing query-cpu-model-* commands.
query-cpu-model-expansion type=static can expand to a versioned
CPU model.

We will probably need to make query-cpu-model-expansion accept a
machine-type name as input, and/or add a new flag meaning "please
give me the best CPU version you have, not the one defined by the
current machine-type".

I'm not sure what would be the best way to encode two types of
information, though:

* Fallback/alternatives info, e.g.: "It makes sense to use
  Haswell-{3.0,2.12,2.5,...} if Haswell-3.1 is not runnable and the
  user asked for Haswell".

* Ordering/preference info, e.g.: "Haswell-3.1 is better than
  Haswell-3.0, prefer the latter"

-- 
Eduardo