1. Patchew
  2. Libvirt
  3. View series

[PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)

Hector Cao posted 1 patch 3 months, 1 week ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20250601231929.19119-1-hector.cao@canonical.com
src/cpu_map/index.xml                    |   2 +
src/cpu_map/meson.build                  |   2 +
src/cpu_map/x86_GraniteRapids-noTSX.xml  | 197 +++++++++++++++++++++++
src/cpu_map/x86_SapphireRapids-noTSX.xml | 190 ++++++++++++++++++++++
4 files changed, 391 insertions(+)
create mode 100644 src/cpu_map/x86_GraniteRapids-noTSX.xml
create mode 100644 src/cpu_map/x86_SapphireRapids-noTSX.xml
[PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
Posted by Hector Cao 3 months, 1 week ago 
Several Intel CPU models with TSX technology (HLE & RTM features) are
affected by the vulnerability TAA[1]. One of the mitigation methods
for TAA is to disable TSX support on the host system. For that purpose,
in 2021, Intel published a microcode update to disable TSX. Linux kernel
also disables TSX globally by default. Even though TSX can be activated via
the kernel command line (tsx=on), many Linux distributions stick with
this default behavior and have TSX disabled. This makes existing CPU
models that have HLE and RTM enabled not correctly detected by
libvirt.

This commit adds 2 remaining -noTSX models:
- SapphireRapids-noTSX
- GraniteRapids-noTSX

Hopefully, this is the last effort on adding noTSX variants since
Granite Rapids should be the last CPU model to have the TSX feature
and is consequently affected by TAA. Indeed, SierraForest does not
have RTM and HLE enabled.

References:

    [1] TAA, TSX asynchronous Abort:
        https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html
---
 src/cpu_map/index.xml                    |   2 +
 src/cpu_map/meson.build                  |   2 +
 src/cpu_map/x86_GraniteRapids-noTSX.xml  | 197 +++++++++++++++++++++++
 src/cpu_map/x86_SapphireRapids-noTSX.xml | 190 ++++++++++++++++++++++
 4 files changed, 391 insertions(+)
 create mode 100644 src/cpu_map/x86_GraniteRapids-noTSX.xml
 create mode 100644 src/cpu_map/x86_SapphireRapids-noTSX.xml

diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml
index 87db338cee..03a2c73ba5 100644
--- a/src/cpu_map/index.xml
+++ b/src/cpu_map/index.xml
@@ -116,10 +116,12 @@
       <include filename='x86_Snowridge-v3.xml'/>
       <include filename='x86_Snowridge-v4.xml'/>
       <include filename='x86_SapphireRapids.xml'/>
+      <include filename='x86_SapphireRapids-noTSX.xml'/>
       <include filename='x86_SapphireRapids-v1.xml'/>
       <include filename='x86_SapphireRapids-v2.xml'/>
       <include filename='x86_SapphireRapids-v3.xml'/>
       <include filename='x86_GraniteRapids.xml'/>
+      <include filename='x86_GraniteRapids-noTSX.xml'/>
       <include filename='x86_GraniteRapids-v1.xml'/>
       <include filename='x86_GraniteRapids-v2.xml'/>
       <include filename='x86_SierraForest.xml'/>
diff --git a/src/cpu_map/meson.build b/src/cpu_map/meson.build
index dee8441a13..414cad7352 100644
--- a/src/cpu_map/meson.build
+++ b/src/cpu_map/meson.build
@@ -80,6 +80,7 @@ cpumap_data = [
   'x86_features.xml',
   'x86_GraniteRapids-v1.xml',
   'x86_GraniteRapids-v2.xml',
+  'x86_GraniteRapids-noTSX.xml',
   'x86_GraniteRapids.xml',
   'x86_Haswell-IBRS.xml',
   'x86_Haswell-noTSX-IBRS.xml',
@@ -148,6 +149,7 @@ cpumap_data = [
   'x86_SapphireRapids-v1.xml',
   'x86_SapphireRapids-v2.xml',
   'x86_SapphireRapids-v3.xml',
+  'x86_SapphireRapids-noTSX.xml',
   'x86_SapphireRapids.xml',
   'x86_SierraForest-v1.xml',
   'x86_SierraForest.xml',
diff --git a/src/cpu_map/x86_GraniteRapids-noTSX.xml b/src/cpu_map/x86_GraniteRapids-noTSX.xml
new file mode 100644
index 0000000000..085b012f83
--- /dev/null
+++ b/src/cpu_map/x86_GraniteRapids-noTSX.xml
@@ -0,0 +1,197 @@
+<cpus>
+  <model name='GraniteRapids-noTSX'>
+    <check partial='compat'/>
+    <decode host='on' guest='off'/>
+    <signature family='6' model='173'/>
+    <vendor name='Intel'/>
+    <feature name='3dnowprefetch'/>
+    <feature name='abm'/>
+    <feature name='adx'/>
+    <feature name='aes'/>
+    <feature name='amx-bf16'/>
+    <feature name='amx-fp16'/>
+    <feature name='amx-int8'/>
+    <feature name='amx-tile'/>
+    <feature name='apic'/>
+    <feature name='arat'/>
+    <feature name='arch-capabilities'/>
+    <feature name='avx'/>
+    <feature name='avx-vnni'/>
+    <feature name='avx2'/>
+    <feature name='avx512-bf16'/>
+    <feature name='avx512-fp16'/>
+    <feature name='avx512-vpopcntdq'/>
+    <feature name='avx512bitalg'/>
+    <feature name='avx512bw'/>
+    <feature name='avx512cd'/>
+    <feature name='avx512dq'/>
+    <feature name='avx512f'/>
+    <feature name='avx512ifma'/>
+    <feature name='avx512vbmi'/>
+    <feature name='avx512vbmi2'/>
+    <feature name='avx512vl'/>
+    <feature name='avx512vnni'/>
+    <feature name='bmi1'/>
+    <feature name='bmi2'/>
+    <feature name='bus-lock-detect'/>
+    <feature name='clflush'/>
+    <feature name='clflushopt'/>
+    <feature name='clwb'/>
+    <feature name='cmov'/>
+    <feature name='cx16'/>
+    <feature name='cx8'/>
+    <feature name='de'/>
+    <feature name='erms'/>
+    <feature name='f16c'/>
+    <feature name='fbsdp-no'/>
+    <feature name='fma'/>
+    <feature name='fpu'/>
+    <feature name='fsgsbase'/>
+    <feature name='fsrc'/>
+    <feature name='fsrm'/>
+    <feature name='fsrs'/>
+    <feature name='fxsr'/>
+    <feature name='fzrm'/>
+    <feature name='gfni'/>
+    <feature name='ibrs-all'/>
+    <feature name='invpcid'/>
+    <feature name='la57'/>
+    <feature name='lahf_lm'/>
+    <feature name='lm'/>
+    <feature name='mca'/>
+    <feature name='mcdt-no'/>
+    <feature name='mce'/>
+    <feature name='mds-no'/>
+    <feature name='mmx'/>
+    <feature name='movbe'/>
+    <feature name='msr'/>
+    <feature name='mtrr'/>
+    <feature name='nx'/>
+    <feature name='pae'/>
+    <feature name='pat'/>
+    <feature name='pbrsb-no'/>
+    <feature name='pcid'/>
+    <feature name='pclmuldq'/>
+    <feature name='pdpe1gb'/>
+    <feature name='pge'/>
+    <feature name='pku'/>
+    <feature name='pni'/>
+    <feature name='popcnt'/>
+    <feature name='prefetchiti'/>
+    <feature name='pschange-mc-no'/>
+    <feature name='psdp-no'/>
+    <feature name='pse'/>
+    <feature name='pse36'/>
+    <feature name='rdctl-no'/>
+    <feature name='rdpid'/>
+    <feature name='rdrand'/>
+    <feature name='rdseed'/>
+    <feature name='rdtscp'/>
+    <feature name='sbdr-ssdp-no'/>
+    <feature name='sep'/>
+    <feature name='serialize'/>
+    <feature name='sha-ni'/>
+    <feature name='skip-l1dfl-vmentry'/>
+    <feature name='smap'/>
+    <feature name='smep'/>
+    <feature name='spec-ctrl'/>
+    <feature name='ssbd'/>
+    <feature name='sse'/>
+    <feature name='sse2'/>
+    <feature name='sse4.1'/>
+    <feature name='sse4.2'/>
+    <feature name='ssse3'/>
+    <feature name='syscall'/>
+    <feature name='taa-no'/>
+    <feature name='tsc'/>
+    <feature name='tsc-deadline'/>
+    <feature name='tsx-ldtrk'/>
+    <feature name='umip'/>
+    <feature name='vaes'/>
+    <feature name='vme'/>
+    <feature name='vmx-activity-hlt'/>
+    <feature name='vmx-apicv-register'/>
+    <feature name='vmx-apicv-vid'/>
+    <feature name='vmx-apicv-x2apic'/>
+    <feature name='vmx-apicv-xapic'/>
+    <feature name='vmx-cr3-load-noexit'/>
+    <feature name='vmx-cr3-store-noexit'/>
+    <feature name='vmx-cr8-load-exit'/>
+    <feature name='vmx-cr8-store-exit'/>
+    <feature name='vmx-desc-exit'/>
+    <feature name='vmx-entry-ia32e-mode'/>
+    <feature name='vmx-entry-load-efer'/>
+    <feature name='vmx-entry-load-pat'/>
+    <feature name='vmx-entry-load-perf-global-ctrl'/>
+    <feature name='vmx-entry-noload-debugctl'/>
+    <feature name='vmx-ept'/>
+    <feature name='vmx-ept-1gb'/>
+    <feature name='vmx-ept-2mb'/>
+    <feature name='vmx-ept-execonly'/>
+    <feature name='vmx-eptad'/>
+    <feature name='vmx-eptp-switching'/>
+    <feature name='vmx-exit-ack-intr'/>
+    <feature name='vmx-exit-load-efer'/>
+    <feature name='vmx-exit-load-pat'/>
+    <feature name='vmx-exit-load-perf-global-ctrl'/>
+    <feature name='vmx-exit-nosave-debugctl'/>
+    <feature name='vmx-exit-save-efer'/>
+    <feature name='vmx-exit-save-pat'/>
+    <feature name='vmx-exit-save-preemption-timer'/>
+    <feature name='vmx-flexpriority'/>
+    <feature name='vmx-hlt-exit'/>
+    <feature name='vmx-ins-outs'/>
+    <feature name='vmx-intr-exit'/>
+    <feature name='vmx-invept'/>
+    <feature name='vmx-invept-all-context'/>
+    <feature name='vmx-invept-single-context'/>
+    <feature name='vmx-invlpg-exit'/>
+    <feature name='vmx-invpcid-exit'/>
+    <feature name='vmx-invvpid'/>
+    <feature name='vmx-invvpid-all-context'/>
+    <feature name='vmx-invvpid-single-addr'/>
+    <feature name='vmx-invvpid-single-context-noglobals'/>
+    <feature name='vmx-io-bitmap'/>
+    <feature name='vmx-io-exit'/>
+    <feature name='vmx-monitor-exit'/>
+    <feature name='vmx-movdr-exit'/>
+    <feature name='vmx-msr-bitmap'/>
+    <feature name='vmx-mtf'/>
+    <feature name='vmx-mwait-exit'/>
+    <feature name='vmx-nmi-exit'/>
+    <feature name='vmx-page-walk-4'/>
+    <feature name='vmx-page-walk-5'/>
+    <feature name='vmx-pause-exit'/>
+    <feature name='vmx-pml'/>
+    <feature name='vmx-posted-intr'/>
+    <feature name='vmx-preemption-timer'/>
+    <feature name='vmx-rdpmc-exit'/>
+    <feature name='vmx-rdrand-exit'/>
+    <feature name='vmx-rdseed-exit'/>
+    <feature name='vmx-rdtsc-exit'/>
+    <feature name='vmx-rdtscp-exit'/>
+    <feature name='vmx-secondary-ctls'/>
+    <feature name='vmx-shadow-vmcs'/>
+    <feature name='vmx-store-lma'/>
+    <feature name='vmx-true-ctls'/>
+    <feature name='vmx-tsc-offset'/>
+    <feature name='vmx-unrestricted-guest'/>
+    <feature name='vmx-vintr-pending'/>
+    <feature name='vmx-vmfunc'/>
+    <feature name='vmx-vmwrite-vmexit-fields'/>
+    <feature name='vmx-vnmi'/>
+    <feature name='vmx-vnmi-pending'/>
+    <feature name='vmx-vpid'/>
+    <feature name='vmx-wbinvd-exit'/>
+    <feature name='vmx-xsaves'/>
+    <feature name='vpclmulqdq'/>
+    <feature name='wbnoinvd'/>
+    <feature name='x2apic'/>
+    <feature name='xfd'/>
+    <feature name='xgetbv1'/>
+    <feature name='xsave'/>
+    <feature name='xsavec'/>
+    <feature name='xsaveopt'/>
+    <feature name='xsaves'/>
+  </model>
+</cpus>
diff --git a/src/cpu_map/x86_SapphireRapids-noTSX.xml b/src/cpu_map/x86_SapphireRapids-noTSX.xml
new file mode 100644
index 0000000000..de56826741
--- /dev/null
+++ b/src/cpu_map/x86_SapphireRapids-noTSX.xml
@@ -0,0 +1,190 @@
+<cpus>
+  <model name='SapphireRapids-noTSX'>
+    <check partial='compat'/>
+    <decode host='on' guest='off'/>
+    <signature family='6' model='143'/>
+    <vendor name='Intel'/>
+    <feature name='3dnowprefetch'/>
+    <feature name='abm'/>
+    <feature name='adx'/>
+    <feature name='aes'/>
+    <feature name='amx-bf16'/>
+    <feature name='amx-int8'/>
+    <feature name='amx-tile'/>
+    <feature name='apic'/>
+    <feature name='arat'/>
+    <feature name='arch-capabilities'/>
+    <feature name='avx'/>
+    <feature name='avx-vnni'/>
+    <feature name='avx2'/>
+    <feature name='avx512-bf16'/>
+    <feature name='avx512-fp16'/>
+    <feature name='avx512-vpopcntdq'/>
+    <feature name='avx512bitalg'/>
+    <feature name='avx512bw'/>
+    <feature name='avx512cd'/>
+    <feature name='avx512dq'/>
+    <feature name='avx512f'/>
+    <feature name='avx512ifma'/>
+    <feature name='avx512vbmi'/>
+    <feature name='avx512vbmi2'/>
+    <feature name='avx512vl'/>
+    <feature name='avx512vnni'/>
+    <feature name='bmi1'/>
+    <feature name='bmi2'/>
+    <feature name='bus-lock-detect'/>
+    <feature name='clflush'/>
+    <feature name='clflushopt'/>
+    <feature name='clwb'/>
+    <feature name='cmov'/>
+    <feature name='cx16'/>
+    <feature name='cx8'/>
+    <feature name='de'/>
+    <feature name='erms'/>
+    <feature name='f16c'/>
+    <feature name='fma'/>
+    <feature name='fpu'/>
+    <feature name='fsgsbase'/>
+    <feature name='fsrc'/>
+    <feature name='fsrm'/>
+    <feature name='fsrs'/>
+    <feature name='fxsr'/>
+    <feature name='fzrm'/>
+    <feature name='gfni'/>
+    <feature name='ibrs-all'/>
+    <feature name='invpcid'/>
+    <feature name='la57'/>
+    <feature name='lahf_lm'/>
+    <feature name='lm'/>
+    <feature name='mca'/>
+    <feature name='mce'/>
+    <feature name='mds-no'/>
+    <feature name='mmx'/>
+    <feature name='movbe'/>
+    <feature name='msr'/>
+    <feature name='mtrr'/>
+    <feature name='nx'/>
+    <feature name='pae'/>
+    <feature name='pat'/>
+    <feature name='pcid'/>
+    <feature name='pclmuldq'/>
+    <feature name='pdpe1gb'/>
+    <feature name='pge'/>
+    <feature name='pku'/>
+    <feature name='pni'/>
+    <feature name='popcnt'/>
+    <feature name='pschange-mc-no'/>
+    <feature name='pse'/>
+    <feature name='pse36'/>
+    <feature name='rdctl-no'/>
+    <feature name='rdpid'/>
+    <feature name='rdrand'/>
+    <feature name='rdseed'/>
+    <feature name='rdtscp'/>
+    <feature name='sep'/>
+    <feature name='serialize'/>
+    <feature name='sha-ni'/>
+    <feature name='skip-l1dfl-vmentry'/>
+    <feature name='smap'/>
+    <feature name='smep'/>
+    <feature name='spec-ctrl'/>
+    <feature name='ssbd'/>
+    <feature name='sse'/>
+    <feature name='sse2'/>
+    <feature name='sse4.1'/>
+    <feature name='sse4.2'/>
+    <feature name='ssse3'/>
+    <feature name='syscall'/>
+    <feature name='taa-no'/>
+    <feature name='tsc'/>
+    <feature name='tsc-deadline'/>
+    <feature name='tsx-ldtrk'/>
+    <feature name='umip'/>
+    <feature name='vaes'/>
+    <feature name='vme'/>
+    <feature name='vmx-activity-hlt' added='yes'/>
+    <feature name='vmx-apicv-register' added='yes'/>
+    <feature name='vmx-apicv-vid' added='yes'/>
+    <feature name='vmx-apicv-x2apic' added='yes'/>
+    <feature name='vmx-apicv-xapic' added='yes'/>
+    <feature name='vmx-cr3-load-noexit' added='yes'/>
+    <feature name='vmx-cr3-store-noexit' added='yes'/>
+    <feature name='vmx-cr8-load-exit' added='yes'/>
+    <feature name='vmx-cr8-store-exit' added='yes'/>
+    <feature name='vmx-desc-exit' added='yes'/>
+    <feature name='vmx-entry-ia32e-mode' added='yes'/>
+    <feature name='vmx-entry-load-efer' added='yes'/>
+    <feature name='vmx-entry-load-pat' added='yes'/>
+    <feature name='vmx-entry-load-perf-global-ctrl' added='yes'/>
+    <feature name='vmx-entry-noload-debugctl' added='yes'/>
+    <feature name='vmx-ept' added='yes'/>
+    <feature name='vmx-ept-1gb' added='yes'/>
+    <feature name='vmx-ept-2mb' added='yes'/>
+    <feature name='vmx-ept-execonly' added='yes'/>
+    <feature name='vmx-eptad' added='yes'/>
+    <feature name='vmx-eptp-switching' added='yes'/>
+    <feature name='vmx-exit-ack-intr' added='yes'/>
+    <feature name='vmx-exit-load-efer' added='yes'/>
+    <feature name='vmx-exit-load-pat' added='yes'/>
+    <feature name='vmx-exit-load-perf-global-ctrl' added='yes'/>
+    <feature name='vmx-exit-nosave-debugctl' added='yes'/>
+    <feature name='vmx-exit-save-efer' added='yes'/>
+    <feature name='vmx-exit-save-pat' added='yes'/>
+    <feature name='vmx-exit-save-preemption-timer' added='yes'/>
+    <feature name='vmx-flexpriority' added='yes'/>
+    <feature name='vmx-hlt-exit' added='yes'/>
+    <feature name='vmx-ins-outs' added='yes'/>
+    <feature name='vmx-intr-exit' added='yes'/>
+    <feature name='vmx-invept' added='yes'/>
+    <feature name='vmx-invept-all-context' added='yes'/>
+    <feature name='vmx-invept-single-context' added='yes'/>
+    <feature name='vmx-invlpg-exit' added='yes'/>
+    <feature name='vmx-invpcid-exit' added='yes'/>
+    <feature name='vmx-invvpid' added='yes'/>
+    <feature name='vmx-invvpid-all-context' added='yes'/>
+    <feature name='vmx-invvpid-single-addr' added='yes'/>
+    <feature name='vmx-invvpid-single-context-noglobals' added='yes'/>
+    <feature name='vmx-io-bitmap' added='yes'/>
+    <feature name='vmx-io-exit' added='yes'/>
+    <feature name='vmx-monitor-exit' added='yes'/>
+    <feature name='vmx-movdr-exit' added='yes'/>
+    <feature name='vmx-msr-bitmap' added='yes'/>
+    <feature name='vmx-mtf' added='yes'/>
+    <feature name='vmx-mwait-exit' added='yes'/>
+    <feature name='vmx-nmi-exit' added='yes'/>
+    <feature name='vmx-page-walk-4' added='yes'/>
+    <feature name='vmx-page-walk-5' added='yes'/>
+    <feature name='vmx-pause-exit' added='yes'/>
+    <feature name='vmx-pml' added='yes'/>
+    <feature name='vmx-posted-intr' added='yes'/>
+    <feature name='vmx-preemption-timer' added='yes'/>
+    <feature name='vmx-rdpmc-exit' added='yes'/>
+    <feature name='vmx-rdrand-exit' added='yes'/>
+    <feature name='vmx-rdseed-exit' added='yes'/>
+    <feature name='vmx-rdtsc-exit' added='yes'/>
+    <feature name='vmx-rdtscp-exit' added='yes'/>
+    <feature name='vmx-secondary-ctls' added='yes'/>
+    <feature name='vmx-shadow-vmcs' added='yes'/>
+    <feature name='vmx-store-lma' added='yes'/>
+    <feature name='vmx-true-ctls' added='yes'/>
+    <feature name='vmx-tsc-offset' added='yes'/>
+    <feature name='vmx-unrestricted-guest' added='yes'/>
+    <feature name='vmx-vintr-pending' added='yes'/>
+    <feature name='vmx-vmfunc' added='yes'/>
+    <feature name='vmx-vmwrite-vmexit-fields' added='yes'/>
+    <feature name='vmx-vnmi' added='yes'/>
+    <feature name='vmx-vnmi-pending' added='yes'/>
+    <feature name='vmx-vpid' added='yes'/>
+    <feature name='vmx-wbinvd-exit' added='yes'/>
+    <feature name='vmx-xsaves' added='yes'/>
+    <feature name='vpclmulqdq'/>
+    <feature name='wbnoinvd'/>
+    <feature name='x2apic'/>
+    <feature name='xfd'/>
+    <feature name='xgetbv1'/>
+    <feature name='xsave'/>
+    <feature name='xsavec'/>
+    <feature name='xsaveopt'/>
+    <feature name='xsaves'/>
+  </model>
+</cpus>
-- 
2.45.2
Re: [PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
Posted by Jiri Denemark via Devel 3 months, 1 week ago 
On Mon, Jun 02, 2025 at 01:19:29 +0200, Hector Cao wrote:
> Several Intel CPU models with TSX technology (HLE & RTM features) are
> affected by the vulnerability TAA[1]. One of the mitigation methods
> for TAA is to disable TSX support on the host system. For that purpose,
> in 2021, Intel published a microcode update to disable TSX. Linux kernel
> also disables TSX globally by default. Even though TSX can be activated via
> the kernel command line (tsx=on), many Linux distributions stick with
> this default behavior and have TSX disabled. This makes existing CPU
> models that have HLE and RTM enabled not correctly detected by
> libvirt.

Can you describe the issue in more details? Especially where libvirt
incorrectly detects CPU models because of this?

> This commit adds 2 remaining -noTSX models:
> - SapphireRapids-noTSX
> - GraniteRapids-noTSX

QEMU switched away from adding suffixes to CPU models and just adds a
new version for a CPU model in case it needs to be updated. There's no
point adding these models to libvirt. Any CPU model that would only
exist in libvirt would not be directly usable anyway and would have to
be translated to another CPU model.

Jirka
Re: [PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
Posted by Hector Cao 3 months, 1 week ago 
Hello Jiri,

Thanks for the feedback,

On Mon, Jun 2, 2025 at 9:30 AM Jiri Denemark <jdenemar@redhat.com> wrote:

> On Mon, Jun 02, 2025 at 01:19:29 +0200, Hector Cao wrote:
> > Several Intel CPU models with TSX technology (HLE & RTM features) are
> > affected by the vulnerability TAA[1]. One of the mitigation methods
> > for TAA is to disable TSX support on the host system. For that purpose,
> > in 2021, Intel published a microcode update to disable TSX. Linux kernel
> > also disables TSX globally by default. Even though TSX can be activated
> via
> > the kernel command line (tsx=on), many Linux distributions stick with
> > this default behavior and have TSX disabled. This makes existing CPU
> > models that have HLE and RTM enabled not correctly detected by
> > libvirt.
>
> Can you describe the issue in more details? Especially where libvirt
> incorrectly detects CPU models because of this?
>
>
On my platform (Granite Rapids CPU) with TSX disabled by default in the
kernel
The TSX features rtm and hle are missing, per consequence, `virsh
capabilities` detects the CPU as
Icelake-Server-noTSX model.


> > This commit adds 2 remaining -noTSX models:
> > - SapphireRapids-noTSX
> > - GraniteRapids-noTSX
>
> QEMU switched away from adding suffixes to CPU models and just adds a
> new version for a CPU model in case it needs to be updated. There's no
> point adding these models to libvirt. Any CPU model that would only
> exist in libvirt would not be directly usable anyway and would have to
> be translated to another CPU model.
>

I would be grateful if you can provide me some background on what is the
criteria to add a
new version to an existing model. For the case of Intel, how do we know
that we need to
add a new version to the CPU model ?

Beyond the naming issue (version vs suffix), I understand that we stopped
doing what we did for older CPU models
like this commit for Icelake, do I understand it correctly ?

i386: Add -noTSX aliases for hle=off, rtm=off CPU models
https://github.com/qemu/qemu/commit/02fa60d10137ed2ef17534718d7467e0d2170142

Do you think that adding a new version for Sapphire and Granite Rapids CPU
models both in QEMU
and libvirt would be something that makes sense to tackle this issue ?


> Jirka
>
>

-- 
Hector CAO
Software Engineer – Partner Engineering Team
hector.cao@canonical.com
https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao
<https://launchpad.net/~hectorcao>

<https://launchpad.net/~hectorcao>
Re: [PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
Posted by Jiří Denemark via Devel 3 months, 1 week ago 
On Mon, Jun 02, 2025 at 14:30:43 +0200, Hector Cao wrote:
> Hello Jiri,
> 
> Thanks for the feedback,
> 
> On Mon, Jun 2, 2025 at 9:30 AM Jiri Denemark <jdenemar@redhat.com> wrote:
> 
> > On Mon, Jun 02, 2025 at 01:19:29 +0200, Hector Cao wrote:
> > > Several Intel CPU models with TSX technology (HLE & RTM features) are
> > > affected by the vulnerability TAA[1]. One of the mitigation methods
> > > for TAA is to disable TSX support on the host system. For that purpose,
> > > in 2021, Intel published a microcode update to disable TSX. Linux kernel
> > > also disables TSX globally by default. Even though TSX can be activated
> > via
> > > the kernel command line (tsx=on), many Linux distributions stick with
> > > this default behavior and have TSX disabled. This makes existing CPU
> > > models that have HLE and RTM enabled not correctly detected by
> > > libvirt.
> >
> > Can you describe the issue in more details? Especially where libvirt
> > incorrectly detects CPU models because of this?
> >
> >
> On my platform (Granite Rapids CPU) with TSX disabled by default in the
> kernel
> The TSX features rtm and hle are missing, per consequence, `virsh
> capabilities` detects the CPU as
> Icelake-Server-noTSX model.

I see, I was thinking this was the case. The CPU definition provided in
host capabilities is limited and cannot cover CPUs that lack some
features compared to the corresponding CPU model and a simpler CPU model
has to be shown instead. Thus this information is mostly useless (except
for checking what exact features a host CPU supports) and it's not used
for anything by libvirt itself. And since we have a much better way of
describing the host CPU or rather a CPU that can be provided to a guest
on the host (virsh domcapabilities --xpath "//cpu/mode[@name='host-model']")
there's no reason other applications or users should look at the CPU in
virsh capabilities either. It's similar to how cpu/topology element in
virsh capabilities is useless and should not be used.

So except for not having the right CPU model in the capabilities XML
(which is not a bug, but rather a known limitation), is there any other
issue? I believe the host CPU would be correctly reported as
SapphireRapids/GraniteRapids with both hle and rtm disabled in domain
capabilities XML.

> > > This commit adds 2 remaining -noTSX models:
> > > - SapphireRapids-noTSX
> > > - GraniteRapids-noTSX
> >
> > QEMU switched away from adding suffixes to CPU models and just adds a
> > new version for a CPU model in case it needs to be updated. There's no
> > point adding these models to libvirt. Any CPU model that would only
> > exist in libvirt would not be directly usable anyway and would have to
> > be translated to another CPU model.
> >
> 
> I would be grateful if you can provide me some background on what is the
> criteria to add a
> new version to an existing model. For the case of Intel, how do we know
> that we need to
> add a new version to the CPU model ?

I don't know, you'd need to ask QEMU developers.

> Beyond the naming issue (version vs suffix), I understand that we stopped
> doing what we did for older CPU models
> like this commit for Icelake, do I understand it correctly ?
> 
> i386: Add -noTSX aliases for hle=off, rtm=off CPU models
> https://github.com/qemu/qemu/commit/02fa60d10137ed2ef17534718d7467e0d2170142

This was the original approach for creating modified CPU models that can
be used as-is without having to manually specify bunch of features. But
when more cases appeared they realized such approach didn't scale and
switched to versioned CPU models with -v* suffixes instead.

> Do you think that adding a new version for Sapphire and Granite Rapids
> CPU models both in QEMU and libvirt would be something that makes
> sense to tackle this issue ?

Well, you can try asking whether adding such CPU model in QEMU would
make sense. From libvirt's POV this is just a cosmetic issue so not
worth the effort IMHO.

Jirka
Re: [PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
Posted by Hector Cao 2 months, 3 weeks ago 
On Mon, Jun 2, 2025 at 3:23 PM Jiří Denemark <jdenemar@redhat.com> wrote:

> On Mon, Jun 02, 2025 at 14:30:43 +0200, Hector Cao wrote:
> > Hello Jiri,
> >
> > Thanks for the feedback,
> >
> > On Mon, Jun 2, 2025 at 9:30 AM Jiri Denemark <jdenemar@redhat.com>
> wrote:
> >
> > > On Mon, Jun 02, 2025 at 01:19:29 +0200, Hector Cao wrote:
> > > > Several Intel CPU models with TSX technology (HLE & RTM features) are
> > > > affected by the vulnerability TAA[1]. One of the mitigation methods
> > > > for TAA is to disable TSX support on the host system. For that
> purpose,
> > > > in 2021, Intel published a microcode update to disable TSX. Linux
> kernel
> > > > also disables TSX globally by default. Even though TSX can be
> activated
> > > via
> > > > the kernel command line (tsx=on), many Linux distributions stick with
> > > > this default behavior and have TSX disabled. This makes existing CPU
> > > > models that have HLE and RTM enabled not correctly detected by
> > > > libvirt.
> > >
> > > Can you describe the issue in more details? Especially where libvirt
> > > incorrectly detects CPU models because of this?
> > >
> > >
> > On my platform (Granite Rapids CPU) with TSX disabled by default in the
> > kernel
> > The TSX features rtm and hle are missing, per consequence, `virsh
> > capabilities` detects the CPU as
> > Icelake-Server-noTSX model.
>
> I see, I was thinking this was the case. The CPU definition provided in
> host capabilities is limited and cannot cover CPUs that lack some
> features compared to the corresponding CPU model and a simpler CPU model
> has to be shown instead. Thus this information is mostly useless (except
> for checking what exact features a host CPU supports) and it's not used
> for anything by libvirt itself. And since we have a much better way of
> describing the host CPU or rather a CPU that can be provided to a guest
> on the host (virsh domcapabilities --xpath
> "//cpu/mode[@name='host-model']")
> there's no reason other applications or users should look at the CPU in
> virsh capabilities either. It's similar to how cpu/topology element in
> virsh capabilities is useless and should not be used.
>
> So except for not having the right CPU model in the capabilities XML
> (which is not a bug, but rather a known limitation), is there any other
> issue? I believe the host CPU would be correctly reported as
> SapphireRapids/GraniteRapids with both hle and rtm disabled in domain
> capabilities XML.
>
>
Yes, you are right, if rtm and hle features are available, Granite Rapids
will be correctly reported by virsh capabilities
if the MSR bug is fixed (please take a look at :
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/XNOHU7PODTZVCX7ZQ2PBM7DRQRG2D6C7/
)

You are also right that this is not a bug but rather a known limitation.
However, we are getting regular bug reports from users who are not aware of
this known limitation and
are confused. I would think if we can offer a better experience and save
time for everyone, It might be worth the
effort, especially GraniteRapids would be the last CPU model affected by
this issue.

If you still believe that this little effort is not useful, I would think
that we can tackle this issue by
offering better documentation about this known limitation. What do you
think ?
We are thinking about documenting it on Ubuntu but do you think that we can
do something more upstream ?

Thanks !

> > > This commit adds 2 remaining -noTSX models:
> > > > - SapphireRapids-noTSX
> > > > - GraniteRapids-noTSX
> > >
> > > QEMU switched away from adding suffixes to CPU models and just adds a
> > > new version for a CPU model in case it needs to be updated. There's no
> > > point adding these models to libvirt. Any CPU model that would only
> > > exist in libvirt would not be directly usable anyway and would have to
> > > be translated to another CPU model.
> > >
> >
> > I would be grateful if you can provide me some background on what is the
> > criteria to add a
> > new version to an existing model. For the case of Intel, how do we know
> > that we need to
> > add a new version to the CPU model ?
>
> I don't know, you'd need to ask QEMU developers.
>
> > Beyond the naming issue (version vs suffix), I understand that we stopped
> > doing what we did for older CPU models
> > like this commit for Icelake, do I understand it correctly ?
> >
> > i386: Add -noTSX aliases for hle=off, rtm=off CPU models
> >
> https://github.com/qemu/qemu/commit/02fa60d10137ed2ef17534718d7467e0d2170142
>
> This was the original approach for creating modified CPU models that can
> be used as-is without having to manually specify bunch of features. But
> when more cases appeared they realized such approach didn't scale and
> switched to versioned CPU models with -v* suffixes instead.
>
> > Do you think that adding a new version for Sapphire and Granite Rapids
> > CPU models both in QEMU and libvirt would be something that makes
> > sense to tackle this issue ?
>
> Well, you can try asking whether adding such CPU model in QEMU would
> make sense. From libvirt's POV this is just a cosmetic issue so not
> worth the effort IMHO.
>
> Jirka
>
>

-- 
Hector CAO
Software Engineer – Partner Engineering Team
hector.cao@canonical.com
https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao
<https://launchpad.net/~hectorcao>

<https://launchpad.net/~hectorcao>
Re: [PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
Posted by Jiří Denemark via Devel 2 months, 3 weeks ago 
On Mon, Jun 16, 2025 at 02:14:15 +0200, Hector Cao wrote:
> On Mon, Jun 2, 2025 at 3:23 PM Jiří Denemark <jdenemar@redhat.com> wrote:
> > So except for not having the right CPU model in the capabilities XML
> > (which is not a bug, but rather a known limitation), is there any other
> > issue? I believe the host CPU would be correctly reported as
> > SapphireRapids/GraniteRapids with both hle and rtm disabled in domain
> > capabilities XML.
> >
> >
> Yes, you are right, if rtm and hle features are available, Granite Rapids
> will be correctly reported by virsh capabilities
> if the MSR bug is fixed (please take a look at :
> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/XNOHU7PODTZVCX7ZQ2PBM7DRQRG2D6C7/
> )
> 
> You are also right that this is not a bug but rather a known limitation.
> However, we are getting regular bug reports from users who are not aware of
> this known limitation and
> are confused. I would think if we can offer a better experience and save
> time for everyone, It might be worth the
> effort, especially GraniteRapids would be the last CPU model affected by
> this issue.

A better experience that would actually work would be allowing CPU
features to be shown as disabled in host capabilities. But unfortunately
we can't do that for compatibility reasons. The CPU description in host
capabilities does not include the "policy" attribute and adding it could
result in apps thinking disabled features are actually enabled (because
they don't know they should read an extra attribute).

> If you still believe that this little effort is not useful, I would think

I do. It would only fix a few specific cases, but the same issue could
happen with other (even existing) CPU models and different features too.
It just depends on the exact host CPU and even BIOS settings.

> that we can tackle this issue by offering better documentation about
> this known limitation. What do you think ? We are thinking about
> documenting it on Ubuntu but do you think that we can do something
> more upstream ?

Yes, this should be fixed by a documentation. It should definitely go
upstream (and any relevant downstream documentation as well) unless it's
already there or in case it's clear enough or not in the right place.

Jirka
Re: [PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
Posted by Hector Cao 2 months, 3 weeks ago 
On Mon, Jun 16, 2025 at 2:39 PM Jiří Denemark <jdenemar@redhat.com> wrote:

> On Mon, Jun 16, 2025 at 02:14:15 +0200, Hector Cao wrote:
> > On Mon, Jun 2, 2025 at 3:23 PM Jiří Denemark <jdenemar@redhat.com>
> wrote:
> > > So except for not having the right CPU model in the capabilities XML
> > > (which is not a bug, but rather a known limitation), is there any other
> > > issue? I believe the host CPU would be correctly reported as
> > > SapphireRapids/GraniteRapids with both hle and rtm disabled in domain
> > > capabilities XML.
> > >
> > >
> > Yes, you are right, if rtm and hle features are available, Granite Rapids
> > will be correctly reported by virsh capabilities
> > if the MSR bug is fixed (please take a look at :
> >
> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/XNOHU7PODTZVCX7ZQ2PBM7DRQRG2D6C7/
> > )
> >
> > You are also right that this is not a bug but rather a known limitation.
> > However, we are getting regular bug reports from users who are not aware
> of
> > this known limitation and
> > are confused. I would think if we can offer a better experience and save
> > time for everyone, It might be worth the
> > effort, especially GraniteRapids would be the last CPU model affected by
> > this issue.
>
> A better experience that would actually work would be allowing CPU
> features to be shown as disabled in host capabilities. But unfortunately
> we can't do that for compatibility reasons. The CPU description in host
> capabilities does not include the "policy" attribute and adding it could
> result in apps thinking disabled features are actually enabled (because
> they don't know they should read an extra attribute).
>
> > If you still believe that this little effort is not useful, I would think
>
> I do. It would only fix a few specific cases, but the same issue could
> happen with other (even existing) CPU models and different features too.
> It just depends on the exact host CPU and even BIOS settings.
>
> > that we can tackle this issue by offering better documentation about
> > this known limitation. What do you think ? We are thinking about
> > documenting it on Ubuntu but do you think that we can do something
> > more upstream ?
>
> Yes, this should be fixed by a documentation. It should definitely go
> upstream (and any relevant downstream documentation as well) unless it's
> already there or in case it's clear enough or not in the right place.
>
>
Do you have in mind any upstream documentation place where we can add this
kind of documentation ?

I see this page
https://wiki.libvirt.org/Libvirt_identifies_host_processor_as_a_different_model_from_the_hardware_documentation.html
I think it can be a good candidate.

What do you think ?

I would help document it if you think that is ok.

Hector.


> Jirka
>
>

-- 
Hector CAO
Software Engineer – Partner Engineering Team
hector.cao@canonical.com
https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao
<https://launchpad.net/~hectorcao>

<https://launchpad.net/~hectorcao>
Re: [PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
Posted by Jiří Denemark via Devel 2 months, 3 weeks ago 
On Mon, Jun 16, 2025 at 16:27:48 +0200, Hector Cao wrote:
> On Mon, Jun 16, 2025 at 2:39 PM Jiří Denemark <jdenemar@redhat.com> wrote:
> > Yes, this should be fixed by a documentation. It should definitely go
> > upstream (and any relevant downstream documentation as well) unless it's
> > already there or in case it's clear enough or not in the right place.
> >
> >
> Do you have in mind any upstream documentation place where we can add this
> kind of documentation ?
> 
> I see this page
> https://wiki.libvirt.org/Libvirt_identifies_host_processor_as_a_different_model_from_the_hardware_documentation.html
> I think it can be a good candidate.

I didn't even know this page existed :-) But yeah, it could be rewritten
to talk about the inability of virsh capabilities to properly describe
the host CPU using the right CPU model. Another place this should be
mentioned is https://libvirt.org/formatcaps.html

> I would help document it if you think that is ok.

Oh sure, documentation enhancements are always welcome :-)

Jirka

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.