On Thu, Nov 21, 2024 at 07:03:13PM +0100, Jiri Denemark wrote: > On Thu, Nov 21, 2024 at 16:14:58 +0100, Jiri Denemark wrote: > > On Wed, Nov 20, 2024 at 14:41:29 +0000, Daniel P. Berrangé wrote: > > > $ virsh domcapabilities --xpath '//model' | grep Skylake-Client > > > <model usable="no" vendor="Intel" canonical="Skylake-Client-v1">Skylake-Client</model> > > > <model usable="no" vendor="Intel" canonical="Skylake-Client-v2">Skylake-Client-IBRS</model> > > > <model usable="no" vendor="Intel" canonical="Skylake-Client-v3">Skylake-Client-noTSX-IBRS</model> > > > <model usable="no" vendor="Intel">Skylake-Client-v4</model> > > I'm thinking about the benefit of knowing what CPU model is an alias and > which one is canonical for apps. I guess they only need to know what > models are supported on all hosts to select one that can be migrated > everywhere. Wouldn't it be better to have the following instead? > > <model usable='yes' vendor='Intel' base='Skylake-Client' version='3'>Skylake-Client-noTSX-IBRS</model> > <model usable='yes' vendor='Intel' base='Skylake-Client' version='3'>Skylake-Client-v3</model> > > Apps could then easily select the latest version of a specific model or > similar stuff without having to parse model names. If they really wanted > they could even deduce Skylake-Client-noTSX-IBRS and Skylake-Client-v3 > are in fact the same CPU model. The problem with this is that at the QAPI level, QEMU does not express any concept of "sequence of versioned models", nor a "base" model. The "-vNNN" suffixes are just a naming convention it happens to use currently. Humans can think it is a version sequence, but QEMU's not defined that as an API promise. The other thing to be wary of is that "bigger" versions does not imply "better", or "newer", or still runnable. A version simply reflects the order in which they were added to QEMU for whatever reason that was created. I'd probably consider them "variants" rather than "versions" and not suggest a particular ordering.
