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