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

[Eduardo Habkost <ehabkost@redhat.com>]

On Fri, Jun 29, 2018 at 02:12:51PM +0200, Jiri Denemark wrote:
> On Fri, Jun 29, 2018 at 11:14:17 +0100, Daniel P. Berrangé wrote:
> > On Thu, Jun 28, 2018 at 04:52:27PM -0300, Eduardo Habkost wrote:
> > > 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.
> > 
> > True, for full back compat with existing libvirt we would probably
> > want to opt-in to it.
> > 
> > eg  -cpu Haswell could pick a fixed Haswell--XXX version according
> > to the machine type.  -cpu Haswell,best=on  could pick best version
> > for the host with the caveat about migration between heterogenous
> > hosts.
> 
> I was thinking we could even separate the CPU model version from the
> name itself:
> 
>     -cpu Haswell                    (the old, compatible way)
>     -cpu Haswell,version=best
>     -cpu Haswell,version=2.12.0

That's a nice idea.  The only problem I see is that this:

  -> query-cpu-model-expansion type=static model=Haswell
  <- { model: { name: "Haswell-2.12.0" } }

is returning a static CPU model ("Haswell-2.12.0") on
`model.name`, which matches the documentation for type=static.
But this:

  -> query-cpu-model-expansion type=static model=Haswell
  <- { model: { name: "Haswell", version="2.12.0" } }

is returning a non-static CPU model name ("Haswell") on
`model.name`, which breaks the existing documentation of
type=static ("Expand to a static CPU model, a combination of a
static base model name and property delta changes").

Maybe this would work:

  -> query-cpu-model-expansion type=static model=Haswell
  <- { model: { name: "Haswell-base", version="2.12.0" } }

"Haswell-base" would be a static CPU model.  "Haswell" would be a
non-static but migration-safe CPU model (which is already the
case today).

Having a "Haswell-2.12.0" alias (that looks like a regular CPU
model) for legacy management management software would be
possible too.

-- 
Eduardo