This is not necessarily intended as a finished proposal, but as a discussion
starter. I mentioned in an email last week that for SEV-SNP support we will
need to be able to specify versioned CPU models that are not yet supported by
libvirt. Rather than just adding a versioned CPU or two that would satisfy my
immediate need, I decided to try to add versioned CPUs in a standard way. This
involves adding the concept of an 'alias' for a CPU model in libvirt. Qemu
already has the concept of a CPU alias for a versioned CPU. In fact, libvirt
already provides a select subset of these as configurable CPU models (e.g.
'EPYC-IBPB'). After this patchset, these aliased CPU versions would be
configurable by either their versioned name ('EPYC-v2') or their alias
('EPYC-IBPB'). And it would also provide non-aliased CPU versions as options
within libvirt ('EPYC-v4').

Assuming that we want to offer all versioned CPUs like this, there are two
approaches to naming. I chose to maintain the existing names (e.g. EPYC-IBPB)
as the primary name where available, and use the versioned name (EPYC-v2) as
the alias. However, some CPU models don't have an alias, so their versioned
name would be their primary name. So we have the following set of 'EPYC' CPU
models:
 - EPYC (alias = EPYC-v1)
 - EPYC-IBPB (alias = EPYC-v2)
 - EPYC-v3 (no alias)
 - EPYC-v4 (no alias)

An alternative approach is something more like:
 - EPYC-v1 (alias = EPYC)
 - EPYC-v2 (alias = EPYC-IBPB)
 - EPYC-v3 (no alias)
 - EPYC-v4 (no alias)

The naming of the second set is more consistent, but it could result in slight
changes to behavior. For example, any call to cpuDecode() that returned
EPYC-IBPB in the past might now return EPYC-v2. These two CPUs are just two
different names for the same model, so I'm not sure it would result in any
issues. But in this patch series I went with the first approach since it
maintained stability and resulted in less churn in the test output.

Note also that there are a couple of patches that update existing CPU models by
re-running this script against the current qemu source code. For example, the
patch "cpu_map: Update EPYC cpu definitions from qemu" results in some minor
changes to the existing EPYC CPUs by adding a couple of feature flags. In
theory, it seems like a good idea for our libvirt models to match how the model
is defined in qemu, but I admit that I don't have a great understanding of
whether this will result in undesirable side-effects. I'm hoping those of you
with deeper knowledge will tell me why this is or is not a good idea. In the
same vein, I've included the last patch of the series showing what it would
look like if we regenerated all of the other CPU definitions from the qemu
source code.

Jonathon Jongsma (19):
  cpu_map: update script to generate versioned CPUs
  cpu: handle aliases in CPU definitions
  cpu_map: Update EPYC cpu definitions from qemu
  cpu_map: Add versioned EPYC CPUs
  cpu_map: Add versioned Intel Nehalem CPUs
  cpu_map: Add versioned Intel Westmere CPUs
  cpu_map: Add versioned Intel SandyBridge CPUs
  cpu_map: Add versioned Intel IvyBridge CPUs
  cpu_map: Add versioned Intel Haswell CPUs
  cpu_map: Add versioned Intel Broadwell CPUs
  cpu_map: Add versioned Intel Skylake CPUs
  cpu_map: Add versioned Intel Cascadelake CPUs
  cpu_map: Add versioned Intel Icelake CPUs
  cpu_map: Add versioned Intel Cooperlake CPUs
  cpu_map: Add versioned Intel Snowridge CPUs
  cpu_map: Add versioned Intel SapphireRapids CPUs
  cpu_map: Add versioned Dhyana CPUs
  cpu: advertise CPU aliases
  NOMERGE: RFC: regenerate all cpu definitions

 src/cpu/cpu_x86.c                             |  88 ++++++++----
 src/cpu_map/index.xml                         |  22 +++
 src/cpu_map/meson.build                       |  22 +++
 src/cpu_map/sync_qemu_models_i386.py          |  44 ++++--
 src/cpu_map/x86_Broadwell-IBRS.xml            |  19 ++-
 src/cpu_map/x86_Broadwell-noTSX-IBRS.xml      |  19 ++-
 src/cpu_map/x86_Broadwell-noTSX.xml           |  19 ++-
 src/cpu_map/x86_Broadwell.xml                 |  18 ++-
 src/cpu_map/x86_Cascadelake-Server-noTSX.xml  |  19 ++-
 src/cpu_map/x86_Cascadelake-Server-v2.xml     |  93 +++++++++++++
 src/cpu_map/x86_Cascadelake-Server-v4.xml     |  91 +++++++++++++
 src/cpu_map/x86_Cascadelake-Server-v5.xml     |  92 +++++++++++++
 src/cpu_map/x86_Cascadelake-Server.xml        |  11 +-
 src/cpu_map/x86_Cooperlake-v2.xml             |  98 ++++++++++++++
 src/cpu_map/x86_Cooperlake.xml                |   9 +-
 src/cpu_map/x86_Dhyana-v2.xml                 |  81 ++++++++++++
 src/cpu_map/x86_Dhyana.xml                    |  13 +-
 src/cpu_map/x86_EPYC-Genoa.xml                |   7 +
 src/cpu_map/x86_EPYC-IBPB.xml                 |  14 +-
 src/cpu_map/x86_EPYC-Milan-v2.xml             | 108 +++++++++++++++
 src/cpu_map/x86_EPYC-Milan.xml                |   8 ++
 src/cpu_map/x86_EPYC-Rome-v2.xml              |  93 +++++++++++++
 src/cpu_map/x86_EPYC-Rome-v3.xml              |  95 +++++++++++++
 src/cpu_map/x86_EPYC-Rome-v4.xml              |  94 +++++++++++++
 src/cpu_map/x86_EPYC-Rome.xml                 |   9 ++
 src/cpu_map/x86_EPYC-v3.xml                   |  87 ++++++++++++
 src/cpu_map/x86_EPYC-v4.xml                   |  88 ++++++++++++
 src/cpu_map/x86_EPYC.xml                      |  13 +-
 src/cpu_map/x86_Haswell-IBRS.xml              |  20 ++-
 src/cpu_map/x86_Haswell-noTSX-IBRS.xml        |  20 ++-
 src/cpu_map/x86_Haswell-noTSX.xml             |  20 ++-
 src/cpu_map/x86_Haswell.xml                   |  18 ++-
 src/cpu_map/x86_Icelake-Server-noTSX.xml      |  14 +-
 src/cpu_map/x86_Icelake-Server-v3.xml         | 103 +++++++++++++++
 src/cpu_map/x86_Icelake-Server-v4.xml         | 108 +++++++++++++++
 src/cpu_map/x86_Icelake-Server-v5.xml         | 109 +++++++++++++++
 src/cpu_map/x86_Icelake-Server-v6.xml         | 109 +++++++++++++++
 src/cpu_map/x86_Icelake-Server.xml            |  11 +-
 src/cpu_map/x86_IvyBridge-IBRS.xml            |  13 +-
 src/cpu_map/x86_IvyBridge.xml                 |  12 +-
 src/cpu_map/x86_Nehalem-IBRS.xml              |  14 +-
 src/cpu_map/x86_Nehalem.xml                   |  13 +-
 src/cpu_map/x86_SandyBridge-IBRS.xml          |  14 +-
 src/cpu_map/x86_SandyBridge.xml               |  13 +-
 src/cpu_map/x86_SapphireRapids-v2.xml         | 125 ++++++++++++++++++
 src/cpu_map/x86_SapphireRapids.xml            |   7 +
 src/cpu_map/x86_Skylake-Client-IBRS.xml       |  16 ++-
 src/cpu_map/x86_Skylake-Client-noTSX-IBRS.xml |  18 +--
 src/cpu_map/x86_Skylake-Client-v4.xml         |  77 +++++++++++
 src/cpu_map/x86_Skylake-Client.xml            |  15 ++-
 src/cpu_map/x86_Skylake-Server-IBRS.xml       |  12 +-
 src/cpu_map/x86_Skylake-Server-noTSX-IBRS.xml |  14 +-
 src/cpu_map/x86_Skylake-Server-v4.xml         |  83 ++++++++++++
 src/cpu_map/x86_Skylake-Server-v5.xml         |  85 ++++++++++++
 src/cpu_map/x86_Skylake-Server.xml            |  12 +-
 src/cpu_map/x86_Snowridge-v2.xml              |  78 +++++++++++
 src/cpu_map/x86_Snowridge-v3.xml              |  80 +++++++++++
 src/cpu_map/x86_Snowridge-v4.xml              |  78 +++++++++++
 src/cpu_map/x86_Snowridge.xml                 |  10 +-
 src/cpu_map/x86_Westmere-IBRS.xml             |  13 +-
 src/cpu_map/x86_Westmere.xml                  |  14 +-
 ...4-baseline-Westmere+Nehalem-migratable.xml |   4 +-
 ...86_64-baseline-Westmere+Nehalem-result.xml |   4 +-
 .../x86_64-baseline-features-expanded.xml     |   1 +
 .../x86_64-baseline-features-result.xml       |   2 -
 .../x86_64-baseline-simple-expanded.xml       |   3 +
 .../x86_64-cpuid-Atom-P5362-guest.xml         |   3 +-
 .../x86_64-cpuid-Atom-P5362-host.xml          |   3 -
 .../x86_64-cpuid-Atom-P5362-json.xml          |   3 +-
 .../x86_64-cpuid-Cooperlake-host.xml          |   3 +-
 .../x86_64-cpuid-Core-i5-2500-guest.xml       |   3 -
 .../x86_64-cpuid-Core-i5-2500-host.xml        |   3 -
 .../x86_64-cpuid-Core-i5-2500-json.xml        |   3 -
 .../x86_64-cpuid-Core-i5-2540M-guest.xml      |   3 -
 .../x86_64-cpuid-Core-i5-2540M-host.xml       |   3 -
 .../x86_64-cpuid-Core-i5-2540M-json.xml       |   3 -
 .../x86_64-cpuid-Core-i5-4670T-guest.xml      |   6 +-
 .../x86_64-cpuid-Core-i5-4670T-host.xml       |  19 ++-
 .../x86_64-cpuid-Core-i5-4670T-json.xml       |   6 +-
 .../x86_64-cpuid-Core-i5-650-guest.xml        |   3 -
 .../x86_64-cpuid-Core-i5-650-host.xml         |   3 -
 .../x86_64-cpuid-Core-i5-650-json.xml         |   3 -
 .../x86_64-cpuid-Core-i5-6600-guest.xml       |   1 +
 .../x86_64-cpuid-Core-i5-6600-host.xml        |   1 +
 .../x86_64-cpuid-Core-i5-6600-json.xml        |   1 +
 .../x86_64-cpuid-Core-i7-2600-guest.xml       |   3 -
 .../x86_64-cpuid-Core-i7-2600-host.xml        |   3 -
 .../x86_64-cpuid-Core-i7-2600-json.xml        |   3 -
 ...6_64-cpuid-Core-i7-2600-xsaveopt-guest.xml |   2 -
 ...86_64-cpuid-Core-i7-2600-xsaveopt-host.xml |   9 +-
 ...86_64-cpuid-Core-i7-2600-xsaveopt-json.xml |   2 -
 .../x86_64-cpuid-Core-i7-3520M-guest.xml      |   2 -
 .../x86_64-cpuid-Core-i7-3520M-host.xml       |   2 -
 .../x86_64-cpuid-Core-i7-3740QM-guest.xml     |   2 +-
 .../x86_64-cpuid-Core-i7-3740QM-host.xml      |  13 +-
 .../x86_64-cpuid-Core-i7-3740QM-json.xml      |   2 +-
 .../x86_64-cpuid-Core-i7-3770-guest.xml       |   2 -
 .../x86_64-cpuid-Core-i7-3770-host.xml        |   2 -
 .../x86_64-cpuid-Core-i7-3770-json.xml        |   2 +-
 .../x86_64-cpuid-Core-i7-4510U-guest.xml      |   6 -
 .../x86_64-cpuid-Core-i7-4510U-host.xml       |   3 -
 .../x86_64-cpuid-Core-i7-4510U-json.xml       |   6 -
 .../x86_64-cpuid-Core-i7-4600U-guest.xml      |   6 -
 .../x86_64-cpuid-Core-i7-4600U-host.xml       |   6 -
 .../x86_64-cpuid-Core-i7-4600U-json.xml       |   6 -
 .../x86_64-cpuid-Core-i7-5600U-arat-guest.xml |   6 -
 .../x86_64-cpuid-Core-i7-5600U-arat-host.xml  |   6 -
 .../x86_64-cpuid-Core-i7-5600U-arat-json.xml  |   6 +-
 .../x86_64-cpuid-Core-i7-5600U-guest.xml      |   6 -
 .../x86_64-cpuid-Core-i7-5600U-host.xml       |   6 -
 .../x86_64-cpuid-Core-i7-5600U-ibrs-guest.xml |   6 -
 .../x86_64-cpuid-Core-i7-5600U-ibrs-host.xml  |   6 -
 .../x86_64-cpuid-Core-i7-5600U-ibrs-json.xml  |   6 -
 .../x86_64-cpuid-Core-i7-5600U-json.xml       |   6 -
 .../x86_64-cpuid-Core-i7-7600U-guest.xml      |   1 +
 .../x86_64-cpuid-Core-i7-7600U-host.xml       |   1 +
 .../x86_64-cpuid-Core-i7-7600U-json.xml       |   1 +
 .../x86_64-cpuid-Core-i7-7700-guest.xml       |   1 +
 .../x86_64-cpuid-Core-i7-7700-host.xml        |   1 +
 .../x86_64-cpuid-Core-i7-7700-json.xml        |   1 +
 .../x86_64-cpuid-Core-i7-8550U-guest.xml      |   5 +-
 .../x86_64-cpuid-Core-i7-8550U-host.xml       |   4 +-
 .../x86_64-cpuid-Core-i7-8550U-json.xml       |   5 +-
 .../x86_64-cpuid-Core-i7-8700-guest.xml       |   1 +
 .../x86_64-cpuid-Core-i7-8700-host.xml        |   1 +
 .../x86_64-cpuid-Core-i7-8700-json.xml        |   1 +
 .../x86_64-cpuid-EPYC-7502-32-Core-guest.xml  |   1 -
 .../x86_64-cpuid-EPYC-7502-32-Core-host.xml   |   5 +-
 .../x86_64-cpuid-EPYC-7502-32-Core-json.xml   |   1 -
 .../x86_64-cpuid-EPYC-7601-32-Core-guest.xml  |   9 +-
 .../x86_64-cpuid-EPYC-7601-32-Core-host.xml   |   2 -
 ..._64-cpuid-EPYC-7601-32-Core-ibpb-guest.xml |   2 -
 ...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml |   8 +-
 ...6_64-cpuid-EPYC-7601-32-Core-ibpb-json.xml |   3 -
 .../x86_64-cpuid-EPYC-7601-32-Core-json.xml   |   3 -
 ..._64-cpuid-Hygon-C86-7185-32-core-guest.xml |   5 +-
 ...6_64-cpuid-Hygon-C86-7185-32-core-host.xml |   5 +-
 ...6_64-cpuid-Hygon-C86-7185-32-core-json.xml |   3 -
 .../x86_64-cpuid-Ice-Lake-Server-guest.xml    |   1 +
 .../x86_64-cpuid-Ice-Lake-Server-host.xml     |   1 +
 .../x86_64-cpuid-Ice-Lake-Server-json.xml     |   2 +-
 .../x86_64-cpuid-Pentium-P6100-guest.xml      |  10 +-
 ...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml |   9 +-
 ...64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml |   2 -
 ...64-cpuid-Ryzen-7-1800X-Eight-Core-json.xml |   3 -
 ...6_64-cpuid-Ryzen-9-3900X-12-Core-guest.xml |   1 -
 ...86_64-cpuid-Ryzen-9-3900X-12-Core-host.xml |   1 -
 ...86_64-cpuid-Ryzen-9-3900X-12-Core-json.xml |   1 -
 .../x86_64-cpuid-Xeon-E3-1225-v5-guest.xml    |   1 +
 .../x86_64-cpuid-Xeon-E3-1225-v5-host.xml     |   1 +
 .../x86_64-cpuid-Xeon-E3-1225-v5-json.xml     |   1 +
 .../x86_64-cpuid-Xeon-E3-1245-v5-guest.xml    |   1 +
 .../x86_64-cpuid-Xeon-E3-1245-v5-host.xml     |   1 +
 .../x86_64-cpuid-Xeon-E3-1245-v5-json.xml     |   1 +
 .../x86_64-cpuid-Xeon-E5-2609-v3-guest.xml    |   6 -
 .../x86_64-cpuid-Xeon-E5-2609-v3-host.xml     |   6 -
 .../x86_64-cpuid-Xeon-E5-2609-v3-json.xml     |   6 -
 .../x86_64-cpuid-Xeon-E5-2623-v4-guest.xml    |   6 -
 .../x86_64-cpuid-Xeon-E5-2623-v4-host.xml     |   6 -
 .../x86_64-cpuid-Xeon-E5-2623-v4-json.xml     |   6 -
 .../x86_64-cpuid-Xeon-E5-2630-v3-guest.xml    |   6 -
 .../x86_64-cpuid-Xeon-E5-2630-v3-host.xml     |   6 -
 .../x86_64-cpuid-Xeon-E5-2630-v3-json.xml     |   6 +-
 .../x86_64-cpuid-Xeon-E5-2630-v4-guest.xml    |   6 -
 .../x86_64-cpuid-Xeon-E5-2630-v4-host.xml     |   6 -
 .../x86_64-cpuid-Xeon-E5-2630-v4-json.xml     |   6 -
 .../x86_64-cpuid-Xeon-E5-2650-guest.xml       |   3 -
 .../x86_64-cpuid-Xeon-E5-2650-host.xml        |   3 -
 .../x86_64-cpuid-Xeon-E5-2650-json.xml        |   3 -
 .../x86_64-cpuid-Xeon-E5-2650-v3-guest.xml    |   6 -
 .../x86_64-cpuid-Xeon-E5-2650-v3-host.xml     |   6 -
 .../x86_64-cpuid-Xeon-E5-2650-v3-json.xml     |   6 +-
 .../x86_64-cpuid-Xeon-E5-2650-v4-guest.xml    |   6 -
 .../x86_64-cpuid-Xeon-E5-2650-v4-host.xml     |   6 -
 .../x86_64-cpuid-Xeon-E5-2650-v4-json.xml     |   6 -
 .../x86_64-cpuid-Xeon-E7-4820-guest.xml       |   3 -
 .../x86_64-cpuid-Xeon-E7-4820-host.xml        |   3 -
 .../x86_64-cpuid-Xeon-E7-4820-json.xml        |   4 +-
 .../x86_64-cpuid-Xeon-E7-4830-guest.xml       |   3 -
 .../x86_64-cpuid-Xeon-E7-4830-host.xml        |   3 -
 .../x86_64-cpuid-Xeon-E7-4830-json.xml        |   3 -
 .../x86_64-cpuid-Xeon-E7-8890-v3-guest.xml    |   6 -
 .../x86_64-cpuid-Xeon-E7-8890-v3-host.xml     |   6 -
 .../x86_64-cpuid-Xeon-E7-8890-v3-json.xml     |   6 -
 .../x86_64-cpuid-Xeon-E7540-guest.xml         |   1 -
 .../x86_64-cpuid-Xeon-E7540-host.xml          |   1 -
 .../x86_64-cpuid-Xeon-E7540-json.xml          |   1 -
 .../x86_64-cpuid-Xeon-Gold-5115-guest.xml     |   2 +-
 .../x86_64-cpuid-Xeon-Gold-5115-host.xml      |   2 +-
 .../x86_64-cpuid-Xeon-Gold-5115-json.xml      |   2 +
 .../x86_64-cpuid-Xeon-Gold-6130-guest.xml     |   2 +-
 .../x86_64-cpuid-Xeon-Gold-6130-host.xml      |   2 +-
 .../x86_64-cpuid-Xeon-Gold-6130-json.xml      |   2 +-
 .../x86_64-cpuid-Xeon-Gold-6148-guest.xml     |   3 +-
 .../x86_64-cpuid-Xeon-Gold-6148-host.xml      |   3 +-
 .../x86_64-cpuid-Xeon-Gold-6148-json.xml      |   3 +-
 .../x86_64-cpuid-Xeon-Platinum-8268-guest.xml |   9 +-
 .../x86_64-cpuid-Xeon-Platinum-8268-host.xml  |   9 +-
 .../x86_64-cpuid-Xeon-Platinum-8268-json.xml  |   2 +-
 .../x86_64-cpuid-Xeon-Platinum-9242-guest.xml |   9 +-
 .../x86_64-cpuid-Xeon-Platinum-9242-host.xml  |   9 +-
 .../x86_64-cpuid-Xeon-Platinum-9242-json.xml  |   9 +-
 .../x86_64-cpuid-Xeon-W3520-guest.xml         |   1 -
 .../x86_64-cpuid-Xeon-W3520-host.xml          |   1 -
 .../x86_64-cpuid-Xeon-W3520-json.xml          |   1 -
 ...id-baseline-Broadwell-IBRS+Cascadelake.xml |   6 -
 ..._64-cpuid-baseline-Cascadelake+Icelake.xml |   9 +-
 ...puid-baseline-Cascadelake+Skylake-IBRS.xml |   2 +-
 ..._64-cpuid-baseline-Cascadelake+Skylake.xml |   3 +-
 ...-cpuid-baseline-Cooperlake+Cascadelake.xml |   9 +-
 ...6_64-cpuid-baseline-Cooperlake+Icelake.xml |   9 +-
 .../x86_64-cpuid-baseline-EPYC+Rome.xml       |   3 -
 .../x86_64-cpuid-baseline-Haswell+Skylake.xml |   6 -
 ...-baseline-Haswell-noTSX-IBRS+Broadwell.xml |   6 -
 ...seline-Haswell-noTSX-IBRS+Skylake-IBRS.xml |   6 -
 ...id-baseline-Haswell-noTSX-IBRS+Skylake.xml |   6 -
 .../x86_64-cpuid-baseline-Ryzen+Rome.xml      |   3 -
 ...4-cpuid-baseline-Skylake-Client+Server.xml |   1 +
 .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml  |  33 +++++
 .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml  |  32 +++++
 tests/domaincapsdata/qemu_4.2.0.x86_64.xml    |  33 +++++
 .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml  |  37 ++++++
 .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml  |  36 +++++
 tests/domaincapsdata/qemu_5.0.0.x86_64.xml    |  37 ++++++
 .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml  |  40 +++++-
 .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml  |  39 ++++++
 tests/domaincapsdata/qemu_5.1.0.x86_64.xml    |  40 +++++-
 .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml  |  40 +++++-
 .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml  |  39 ++++++
 tests/domaincapsdata/qemu_5.2.0.x86_64.xml    |  40 +++++-
 .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml  |  42 +++++-
 .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml  |  41 ++++++
 tests/domaincapsdata/qemu_6.0.0.x86_64.xml    |  42 +++++-
 .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml  |  49 ++++++-
 .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml  |  48 +++++++
 tests/domaincapsdata/qemu_6.1.0.x86_64.xml    |  49 ++++++-
 .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml  |  50 ++++++-
 .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml  |  49 +++++++
 tests/domaincapsdata/qemu_6.2.0.x86_64.xml    |  50 ++++++-
 .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml  |  51 ++++++-
 .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml  |  50 +++++++
 tests/domaincapsdata/qemu_7.0.0.x86_64.xml    |  51 ++++++-
 .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml  |  51 ++++++-
 .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml  |  50 +++++++
 tests/domaincapsdata/qemu_7.1.0.x86_64.xml    |  51 ++++++-
 .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml  |  51 ++++++-
 .../qemu_7.2.0-tcg.x86_64+hvf.xml             |  51 ++++++-
 .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml  |  51 ++++++-
 tests/domaincapsdata/qemu_7.2.0.x86_64.xml    |  51 ++++++-
 .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml  |  52 +++++++-
 .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml  |  52 +++++++-
 tests/domaincapsdata/qemu_8.0.0.x86_64.xml    |  52 +++++++-
 .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml  |  61 ++++++++-
 .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml  |  57 +++++++-
 tests/domaincapsdata/qemu_8.1.0.x86_64.xml    |  61 ++++++++-
 .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml  |  61 ++++++++-
 .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml  |  57 +++++++-
 tests/domaincapsdata/qemu_8.2.0.x86_64.xml    |  61 ++++++++-
 ...-Icelake-Server-pconfig.x86_64-latest.args |   2 +-
 .../cpu-fallback.x86_64-5.2.0.args            |   2 +-
 .../cpu-fallback.x86_64-8.0.0.args            |   2 +-
 tests/qemuxml2argvdata/cpu-fallback.xml       |   1 -
 .../cpu-host-model-fallback.x86_64-7.2.0.args |   2 +-
 .../cpu-host-model-fallback.x86_64-8.0.0.args |   2 +-
 ...cpu-host-model-fallback.x86_64-latest.args |   2 +-
 ...pu-host-model-nofallback.x86_64-7.2.0.args |   2 +-
 ...pu-host-model-nofallback.x86_64-8.0.0.args |   2 +-
 ...u-host-model-nofallback.x86_64-latest.args |   2 +-
 .../cpu-host-model.x86_64-4.2.0.args          |   2 +-
 .../cpu-host-model.x86_64-5.0.0.args          |   2 +-
 .../cpu-host-model.x86_64-5.1.0.args          |   2 +-
 .../cpu-host-model.x86_64-5.2.0.args          |   2 +-
 .../cpu-host-model.x86_64-6.0.0.args          |   2 +-
 .../cpu-host-model.x86_64-6.1.0.args          |   2 +-
 .../cpu-host-model.x86_64-6.2.0.args          |   2 +-
 .../cpu-host-model.x86_64-7.0.0.args          |   2 +-
 .../cpu-host-model.x86_64-7.1.0.args          |   2 +-
 .../cpu-host-model.x86_64-7.2.0.args          |   2 +-
 .../cpu-host-model.x86_64-8.0.0.args          |   2 +-
 .../cpu-host-model.x86_64-latest.args         |   2 +-
 .../cpu-nofallback.x86_64-8.0.0.args          |   2 +-
 tests/qemuxml2argvdata/cpu-nofallback.xml     |   1 -
 282 files changed, 4591 insertions(+), 692 deletions(-)
 create mode 100644 src/cpu_map/x86_Cascadelake-Server-v2.xml
 create mode 100644 src/cpu_map/x86_Cascadelake-Server-v4.xml
 create mode 100644 src/cpu_map/x86_Cascadelake-Server-v5.xml
 create mode 100644 src/cpu_map/x86_Cooperlake-v2.xml
 create mode 100644 src/cpu_map/x86_Dhyana-v2.xml
 create mode 100644 src/cpu_map/x86_EPYC-Milan-v2.xml
 create mode 100644 src/cpu_map/x86_EPYC-Rome-v2.xml
 create mode 100644 src/cpu_map/x86_EPYC-Rome-v3.xml
 create mode 100644 src/cpu_map/x86_EPYC-Rome-v4.xml
 create mode 100644 src/cpu_map/x86_EPYC-v3.xml
 create mode 100644 src/cpu_map/x86_EPYC-v4.xml
 create mode 100644 src/cpu_map/x86_Icelake-Server-v3.xml
 create mode 100644 src/cpu_map/x86_Icelake-Server-v4.xml
 create mode 100644 src/cpu_map/x86_Icelake-Server-v5.xml
 create mode 100644 src/cpu_map/x86_Icelake-Server-v6.xml
 create mode 100644 src/cpu_map/x86_SapphireRapids-v2.xml
 create mode 100644 src/cpu_map/x86_Skylake-Client-v4.xml
 create mode 100644 src/cpu_map/x86_Skylake-Server-v4.xml
 create mode 100644 src/cpu_map/x86_Skylake-Server-v5.xml
 create mode 100644 src/cpu_map/x86_Snowridge-v2.xml
 create mode 100644 src/cpu_map/x86_Snowridge-v3.xml
 create mode 100644 src/cpu_map/x86_Snowridge-v4.xml

-- 
2.41.0
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

Hi.

Originally I was thinking about versioned CPU models support as a good
opportunity for redoing the way they are defined in libvirt and the way
we check their compatibility with the current host setup. In other
words, I wanted each new CPU model definition to be probed from QEMU and
drop check="partial" for these new models and rely on CPU runnability
reported by QEMU. But this would require additional support from QEMU,
for which there were some patches sent to the list, but nothing was
really merged in the end.

So I guess we need to accept the situation and add versioned CPU models
the old way without waiting for changes in QEMU that nobody is working
on anyway.

But I wonder if we should still try to change the way we check guest CPU
ABI a bit (for the newly added models) and rely more on QEMU not
changing their CPU models. I believe they will never change an existing
versioned model and introduce a new one instead, is that correct?

On Mon, Nov 06, 2023 at 16:21:05 -0600, Jonathon Jongsma wrote:
> Assuming that we want to offer all versioned CPUs like this, there are two
> approaches to naming. I chose to maintain the existing names (e.g. EPYC-IBPB)
> as the primary name where available, and use the versioned name (EPYC-v2) as
> the alias. However, some CPU models don't have an alias, so their versioned
> name would be their primary name. So we have the following set of 'EPYC' CPU
> models:
>  - EPYC (alias = EPYC-v1)
>  - EPYC-IBPB (alias = EPYC-v2)
>  - EPYC-v3 (no alias)
>  - EPYC-v4 (no alias)
> 
> An alternative approach is something more like:
>  - EPYC-v1 (alias = EPYC)
>  - EPYC-v2 (alias = EPYC-IBPB)
>  - EPYC-v3 (no alias)
>  - EPYC-v4 (no alias)

Hmm, I don't think creating aliases is a good idea, at least on the
public API level. We could perhaps use them internally if needed (and if
QEMU doesn't provide that info) when implementing a transformation of
non-versioned CPUs to versioned ones. But providing the same CPU model
under several different names doesn't seem like a good idea.

> The naming of the second set is more consistent, but it could result in slight
> changes to behavior. For example, any call to cpuDecode() that returned
> EPYC-IBPB in the past might now return EPYC-v2. These two CPUs are just two
> different names for the same model, so I'm not sure it would result in any
> issues. But in this patch series I went with the first approach since it
> maintained stability and resulted in less churn in the test output.

Well the tests are mostly there to avoid such churn because it's indeed
an issue if the same CPU suddenly starts to be recognized as a different
model. Sometimes the change is correct, but most of the time it's not.
So using your example, having EPYC-v2 in domain XML instead of EPYC-IBPB
means you cannot migrate to an libvirt version that doesn't know about
EPYC-v2 despite it being exactly the same as the supported EPYC-IBPB CPU
model. Which is why introducing aliases in public APIs is not a good
idea.

That said, if we want to implement the translation from non-versioned to
versioned CPU models we need to solve migration if Model is translated
as Model-v2, which the other side does not support. I'm afraid we would
need to do some kind of reverse translation here.

> Note also that there are a couple of patches that update existing CPU models by
> re-running this script against the current qemu source code. For example, the
> patch "cpu_map: Update EPYC cpu definitions from qemu" results in some minor
> changes to the existing EPYC CPUs by adding a couple of feature flags. In
> theory, it seems like a good idea for our libvirt models to match how the model
> is defined in qemu, but I admit that I don't have a great understanding of
> whether this will result in undesirable side-effects. I'm hoping those of you
> with deeper knowledge will tell me why this is or is not a good idea.

I've said in my other emails that this is not a good idea so I'll
explain why in detail here. Taking an example from your patch that
updates several EPYC models, let's suppose we have an EPYC CPU model
defined without "npt" and we decide to add "npt" to the model
definition. On the source with new libvirt with this change we
start a domain with the following CPU definition (simplified):

    <cpu>
        <model>EPYC</model>
    </cpu>

Now if the source host cannot provide npt, we're good as the CPU
definition will be translated to something like

    <cpu>
        <model>EPYC</model>
        <feature name="npt" policy="disable"/>
    </cpu>

because we detected that QEMU removed the npt feature even though we
asked for it by using EPYC. But if the host can provide npt the live XML
will not be updated.

    Note, in real world CPUs missing a feature we're adding might not
    actually exist and everything would be fine, but once we're in
    nested environment, everything is possible. Also there are features
    that can be available on a host CPU based on its configuration or
    even microcode revision.

Once we try to migrate such domain to a destination host with older
libvirt without npt in EPYC, it will ask QEMU to run a domain with EPYC
CPU model. In case the destination host cannot provide npt (in contrast
to the source host), the guest will see npt disabled and we won't detect
it as an issue because we didn't know we were asking for it by using
EPYC. Actually, we might still detect it as a list of features QEMU
disabled would not be empty (in case it was new enough to have npt in
EPYC).

And when we want to remove a feature from a model, new libvirt and QEMU
on the source will not provide the removed feature, but older libvirt on
the destination host will require it because the feature is part our the
CPU model definition there.

All this, while using a specific example, was meant rather generally.
And I didn't cover all possible combinations of what can happen on each
side. There might be cases when we can add or drop CPU features from
existing models, but each case needs to be considered separately and be
accompanied with detailed description why such change would not cause
migration issues. And doing so is usually not very pleasant mental
exercise as you can see above :-)

Jirka
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org