For SEV-SNP support we will need to be able to specify versioned CPU models
that are not yet available in libvirt. Rather than just adding a versioned CPU
or two that would satisfy that immediate need, I decided to try to add
versioned CPUs in a more standard way. This series generates CPU definitions
for all cpu versions that are defined in upstream qemu (at least for
recent Intel and AMD CPUs).

libvirt already provides a select subset of these versions as configurable CPU
models. But we only include the ones that have defined aliases in qemu, such as
EPYC-IBPB. After this patchset, all verisioned cpu models supported by qemu
will be available in libvirt.

Note that I'm only adding versions that are not already available via their
alias. For example, I am not adding an EPYC-v2 CPU model since it is already
available as EPYC-IBPB.

Changes in v2:
 - don't make any changes to existing CPU models
 - drop concept of aliases from libvirt and only provide new versioned models
   that aren't already available via their qemu alias.

Jonathon Jongsma (9):
  cpu_map: update script to generate versioned CPUs
  cpu_map: Add versioned EPYC 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

 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_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_Cooperlake-v2.xml             |  98 ++++++++++++++
 src/cpu_map/x86_Dhyana-v2.xml                 |  81 ++++++++++++
 src/cpu_map/x86_EPYC-Milan-v2.xml             | 108 +++++++++++++++
 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-v3.xml                   |  87 ++++++++++++
 src/cpu_map/x86_EPYC-v4.xml                   |  88 ++++++++++++
 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_SapphireRapids-v2.xml         | 125 ++++++++++++++++++
 src/cpu_map/x86_Skylake-Client-v4.xml         |  77 +++++++++++
 src/cpu_map/x86_Skylake-Server-v4.xml         |  83 ++++++++++++
 src/cpu_map/x86_Skylake-Server-v5.xml         |  85 ++++++++++++
 src/cpu_map/x86_Snowridge-v2.xml              |  78 +++++++++++
 src/cpu_map/x86_Snowridge-v3.xml              |  80 +++++++++++
 src/cpu_map/x86_Snowridge-v4.xml              |  78 +++++++++++
 .../x86_64-cpuid-Atom-P5362-guest.xml         |   3 +-
 .../x86_64-cpuid-Atom-P5362-json.xml          |   3 +-
 .../x86_64-cpuid-Cooperlake-host.xml          |   3 +-
 .../x86_64-cpuid-EPYC-7502-32-Core-host.xml   |   5 +-
 .../x86_64-cpuid-EPYC-7601-32-Core-guest.xml  |   9 +-
 ...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml |   8 +-
 ..._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 |   6 +-
 ...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml |   9 +-
 .../x86_64-cpuid-Xeon-Platinum-8268-guest.xml |   9 +-
 .../x86_64-cpuid-Xeon-Platinum-8268-host.xml  |   9 +-
 .../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 +-
 ..._64-cpuid-baseline-Cascadelake+Icelake.xml |   9 +-
 ...-cpuid-baseline-Cooperlake+Cascadelake.xml |   9 +-
 ...6_64-cpuid-baseline-Cooperlake+Icelake.xml |   9 +-
 .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml  |   2 +
 .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml  |   2 +
 tests/domaincapsdata/qemu_4.2.0.x86_64.xml    |   2 +
 .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml  |   4 +
 .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml  |   4 +
 tests/domaincapsdata/qemu_5.0.0.x86_64.xml    |   4 +
 .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml  |   7 +
 .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml  |   7 +
 tests/domaincapsdata/qemu_5.1.0.x86_64.xml    |   7 +
 .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml  |   7 +
 .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml  |   7 +
 tests/domaincapsdata/qemu_5.2.0.x86_64.xml    |   7 +
 .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml  |   8 ++
 .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml  |   8 ++
 tests/domaincapsdata/qemu_6.0.0.x86_64.xml    |   8 ++
 .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml  |  15 +++
 .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml  |  15 +++
 tests/domaincapsdata/qemu_6.1.0.x86_64.xml    |  15 +++
 .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml  |  16 +++
 .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml  |  16 +++
 tests/domaincapsdata/qemu_6.2.0.x86_64.xml    |  16 +++
 .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml  |  17 +++
 .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml  |  17 +++
 tests/domaincapsdata/qemu_7.0.0.x86_64.xml    |  17 +++
 .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml  |  17 +++
 .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml  |  17 +++
 tests/domaincapsdata/qemu_7.1.0.x86_64.xml    |  17 +++
 .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml  |  17 +++
 .../qemu_7.2.0-tcg.x86_64+hvf.xml             |  17 +++
 .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml  |  17 +++
 tests/domaincapsdata/qemu_7.2.0.x86_64.xml    |  17 +++
 .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml  |  17 +++
 .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml  |  17 +++
 tests/domaincapsdata/qemu_8.0.0.x86_64.xml    |  17 +++
 .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml  |  27 +++-
 .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml  |  22 +++
 tests/domaincapsdata/qemu_8.1.0.x86_64.xml    |  27 +++-
 .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml  |  27 +++-
 .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml  |  22 +++
 tests/domaincapsdata/qemu_8.2.0.x86_64.xml    |  27 +++-
 ...-host-model-fallback-kvm.x86_64-8.1.0.args |   2 +-
 ...host-model-fallback-kvm.x86_64-latest.args |   2 +-
 .../cpu-host-model-kvm.x86_64-8.1.0.args      |   2 +-
 .../cpu-host-model-kvm.x86_64-latest.args     |   2 +-
 ...ost-model-nofallback-kvm.x86_64-8.1.0.args |   2 +-
 ...st-model-nofallback-kvm.x86_64-latest.args |   2 +-
 89 files changed, 2710 insertions(+), 123 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

On Thu, Dec 07, 2023 at 04:07:48PM -0600, Jonathon Jongsma wrote:
> For SEV-SNP support we will need to be able to specify versioned CPU models
> that are not yet available in libvirt. Rather than just adding a versioned CPU
> or two that would satisfy that immediate need, I decided to try to add
> versioned CPUs in a more standard way. This series generates CPU definitions
> for all cpu versions that are defined in upstream qemu (at least for
> recent Intel and AMD CPUs).
> 
> libvirt already provides a select subset of these versions as configurable CPU
> models. But we only include the ones that have defined aliases in qemu, such as
> EPYC-IBPB. After this patchset, all verisioned cpu models supported by qemu
> will be available in libvirt.
> 
> Note that I'm only adding versions that are not already available via their
> alias. For example, I am not adding an EPYC-v2 CPU model since it is already
> available as EPYC-IBPB.

That is not reliable, as the alias mapping between a short name "EPYC"
and a version is set by the choice of machine type.

ie one machine type might map EPYC to v1, and another machine type
might map EPYC to v2.

It just happens to be the case that currently all machine types have
the same alias expansion, but that's not guaranteed.

So if we're going down this route, we need to bring in all versioned
machine types.

With 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 :|
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On 12/8/23 5:03 AM, Daniel P. Berrangé wrote:
> On Thu, Dec 07, 2023 at 04:07:48PM -0600, Jonathon Jongsma wrote:
>> For SEV-SNP support we will need to be able to specify versioned CPU models
>> that are not yet available in libvirt. Rather than just adding a versioned CPU
>> or two that would satisfy that immediate need, I decided to try to add
>> versioned CPUs in a more standard way. This series generates CPU definitions
>> for all cpu versions that are defined in upstream qemu (at least for
>> recent Intel and AMD CPUs).
>>
>> libvirt already provides a select subset of these versions as configurable CPU
>> models. But we only include the ones that have defined aliases in qemu, such as
>> EPYC-IBPB. After this patchset, all verisioned cpu models supported by qemu
>> will be available in libvirt.
>>
>> Note that I'm only adding versions that are not already available via their
>> alias. For example, I am not adding an EPYC-v2 CPU model since it is already
>> available as EPYC-IBPB.
> 
> That is not reliable, as the alias mapping between a short name "EPYC"
> and a version is set by the choice of machine type.
> 
> ie one machine type might map EPYC to v1, and another machine type
> might map EPYC to v2.
> 
> It just happens to be the case that currently all machine types have
> the same alias expansion, but that's not guaranteed.
> 
> So if we're going down this route, we need to bring in all versioned
> machine types.
> 

I suppose this is true, but it doesn't seem meaningfully different than 
our current situation where we have already introduced a subset of 
versioned types. It's just that we've only added the ones with 
human-readable names. So while this patch doesn't solve the issue you 
mentioned, I don't think that it makes the situation any worse. We are 
already susceptible to any changes that qemu might make with respect to 
machine-specific CPU aliases. But I'll try to figure out a more 
comprehensive approach.

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