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

Fri Jun 29 12:16:04 UTC 2018

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
> 
> It would be slightly more work for the upper management layers, but IMHO
> it would make more sense.
> 
> In any case, we have to think about keeping guest ABI stable.
> 
> I hope the automatic version selection would not cause any problems for
> subsequent cold starts (such as Windows activation issues). It should be
> very similar to updating CPU microcode which the guest OS is already
> supposed to deal with in real hardware. However, in the past QEMU
> changed CPU signature (family, model, stepping) for new machine types
> and it is likely to happen with separately versioned CPU models too. I
> believe CPU microcode updates do not touch these values. On the other
> hand, it's similar to host-model and the user can always specify exact
> version to avoid this slight change should it be a problem.
> 
> Once the domain starts, we need to keep stable ABI across migrations,
> save/restores, or snapshots. Libvirt already does so by talking to QEMU
> before starting vCPUs and checking for disabled/enabled features. Then
> we store this information in the active domain XML to make sure we can
> enforce the same CPU later. This concept would need to be enhanced to
> include the CPU model version which QEMU would need to be able to
> report.
> 
> A significantly more fun would result from letting libvirt use the
> versioned CPU model stuff by default without an explicit knob in the
> XML. But I guess you don't want to go that direction, do you?

>From libvirt POV I think we have to always fully expand the version
at time of define, in the same way we expand the machine type. Nothing
else can guarantee ABI.

So once you do have a guest and you want to update it to use a newer
version, you'd have to explicitly delete the version from the XML and
let libvirt update it again, similar to how you update existing guest
to new machine type.

We could perhaps make this easier - eg  VIR_DOMAIN_XML_UPDATE_CPU
flag for virDomainDefine/virDomainCreateXML  or similar.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|