[PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
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.h... --- 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
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
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>
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
On Mon, Jun 2, 2025 at 3:23 PM Jiří Denemark <jdenemar@redhat.com> 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
On Mon, Jun 02, 2025 at 14:30:43 +0200, Hector Cao wrote: 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/XNOHU... ) 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>
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/XNOHU... )
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
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/XNOHU...
)
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_mo... 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>
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_mo... 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
participants (3)
-
Hector Cao -
Jiri Denemark -
Jiří Denemark