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.
> > 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"
The version number of course gives an ordering, but we generally
tell people not to assume version is numeric. We could report
an explicit "priority" in some manner against each.
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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
