Intel-SIG: DiamondRapids (DMR) new ISAs enabling - #141
Open
quanxianwang wants to merge 7 commits into
Open
quanxianwang wants to merge 7 commits into
quanxianwang wants to merge 7 commits into
Conversation
commit 1c450ff upstream. Advertise AVX10.1 related CPUIDs, i.e. report AVX10 support bit via CPUID.(EAX=07H, ECX=01H):EDX[bit 19] and new CPUID leaf 0x24H so that guest OS and applications can query the AVX10.1 CPUIDs directly. Intel AVX10 represents the first major new vector ISA since the introduction of Intel AVX512, which will establish a common, converged vector instruction set across all Intel architectures[1]. AVX10.1 is an early version of AVX10, that enumerates the Intel AVX512 instruction set at 128, 256, and 512 bits which is enabled on Granite Rapids. I.e., AVX10.1 is only a new CPUID enumeration with no new functionality. New features, e.g. Embedded Rounding and Suppress All Exceptions (SAE) will be introduced in AVX10.2. Advertising AVX10.1 is safe because there is nothing to enable for AVX10.1, i.e. it's purely a new way to enumerate support, thus there will never be anything for the kernel to enable. Note just the CPUID checking is changed when using AVX512 related instructions, e.g. if using one AVX512 instruction needs to check (AVX512 AND AVX512DQ), it can check ((AVX512 AND AVX512DQ) OR AVX10.1) after checking XCR0[7:5]. The versions of AVX10 are expected to be inclusive, e.g. version N+1 is a superset of version N. Per the spec, the version can never be 0, just advertise AVX10.1 if it's supported in hardware. Moreover, advertising AVX10_{128,256,512} needs to land in the same commit as advertising basic AVX10.1 support, otherwise KVM would advertise an impossible CPU model. E.g. a CPU with AVX512 but not AVX10.1/512 is impossible per the SDM. As more and more AVX related CPUIDs are added (it would have resulted in around 40-50 CPUID flags when developing AVX10), the versioning approach is introduced. But incrementing version numbers are bad for virtualization. E.g. if AVX10.2 has a feature that shouldn't be enumerated to guests for whatever reason, then KVM can't enumerate any "later" features either, because the only way to hide the problematic AVX10.2 feature is to set the version to AVX10.1 or lower[2]. But most AVX features are just passed through and don't have virtualization controls, so AVX10 should not be problematic in practice, so long as Intel honors their promise that future versions will be supersets of past versions. [1] https://cdrdv2.intel.com/v1/dl/getContent/784267 [2] https://lore.kernel.org/all/Zkz5Ak0PQlAN8DxK@google.com/ Intel-SIG: commit 1c450ff KVM: x86: Advertise AVX10.1 CPUID to userspace. DMR ISAs enalbing Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Link: https://lore.kernel.org/r/20240819062327.3269720-1-tao1.su@linux.intel.com [sean: minor changelog tweaks] Signed-off-by: Sean Christopherson <seanjc@google.com> [ Quanxian Wang: amend commit log ] Signed-off-by: Quanxian Wang <quanxian.wang@intel.com>
…caps commit 7ea34578aea728819a2832b6556035050e25fcb7 upstream. Replace the internals of the governed features framework with a more comprehensive "guest CPU capabilities" implementation, i.e. with a guest version of kvm_cpu_caps. Keep the skeleton of governed features around for now as vmx_adjust_sec_exec_control() relies on detecting governed features to do the right thing for XSAVES, and switching all guest feature queries to guest_cpu_cap_has() requires subtle and non-trivial changes, i.e. is best done as a standalone change. Tracking *all* guest capabilities that KVM cares will allow excising the poorly named "governed features" framework, and effectively optimizes all KVM queries of guest capabilities, i.e. doesn't require making a subjective decision as to whether or not a feature is worth "governing", and doesn't require adding the code to do so. The cost of tracking all features is currently 92 bytes per vCPU on 64-bit kernels: 100 bytes for cpu_caps versus 8 bytes for governed_features. That cost is well worth paying even if the only benefit was eliminating the "governed features" terminology. And practically speaking, the real cost is zero unless those 92 bytes pushes the size of vcpu_vmx or vcpu_svm into a new order-N allocation, and if that happens there are better ways to reduce the footprint of kvm_vcpu_arch, e.g. making the PMU and/or MTRR state separate allocations. Intel-SIG: commit 7ea34578aea7 KVM: x86: Replace guts of "governed" features with comprehensive cpu_caps. DMR ISAs enalbing Suggested-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20241128013424.4096668-41-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> [ Quanxian Wang: amend commit log ] Signed-off-by: Quanxian Wang <quanxian.wang@intel.com>
commit f24ef0093dd8cf60ed7f93a82fb16335fdcbc310 upstream.
Define the feature flag for MOVRS and advertise support to userspace when
the feature is supported by the host.
MOVRS is a new set of instructions introduced in the Intel platform
Diamond Rapids, to provide load instructions that carry a read-shared
hint.
Functionally, MOVRS family is equivalent to existing load instructions,
but its read-shared hint indicates that the source memory location is
likely to become read-shared by multiple processors, i.e., read in the
future by at least one other processor before it is written (assuming it
is ever written in the future). This hint could optimize the behavior of
the caches, especially shared caches, for this data for future reads by
multiple processors. Additionally, MOVRS family also includes a software
prefetch instruction, PREFETCHRST2, that carries the same read-shared
hint. [*]
MOVRS family is enumerated by CPUID single-bit (0x7.0x1.EAX[bit 31]).
Since it's on a densely-populated CPUID leaf and some other bits on
this leaf have kernel usages, define this new feature in cpufeatures.h,
but hide it in /proc/cpuinfo due to lack of current kernel usage.
Advertise MOVRS bit to userspace directly. It's safe, since there's no
new VMX controls or additional host enabling required for guests to use
this feature.
[*]: Intel Architecture Instruction Set Extensions and Future Features
(rev.059).
Intel-SIG: commit f24ef0093dd8 KVM: x86: Advertise MOVRS CPUID to userspace.
DMR ISAs enalbing
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Link: https://patch.msgid.link/20251120050720.931449-2-zhao1.liu@intel.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
[ Quanxian Wang: amend commit log ]
Signed-off-by: Quanxian Wang <quanxian.wang@intel.com>
commit 58cbaf64e6530fa37752ff1362129842ac94fee0 upstream.
Define and advertise AMX CPUIDs (0x1E.0x1) to userspace when the leaf is
supported by the host.
Intel Diamond Rapids adds new AMX instructions to support new formats
and memory operations [*], and introduces the CPUID subleaf 0x1E.0x1
to centralize the discrete AMX feature bits within EAX.
Since these AMX features have no actual kernel usages, define them as
KVM-only features in reverse_cpuid.h.
In addition to the new features, CPUID 0x1E.0x1.EAX[bits 0-3] are
aliaseed positions of existing AMX feature bits distributed across the
0x7 leaves. To avoid duplicate feature names, name these aliases with an
*_ALIAS suffix, and define them in reverse_cpuid.h as KVM-only features
as well.
Advertise new CPUID subleaf 0x1E.0x1 with its AMX CPUID feature bits to
userspace for guest use. It's safe since no additional enabling work
is needed in the host kernel.
[*]: Intel Architecture Instruction Set Extensions and Future Features
(rev.059).
Intel-SIG: commit 58cbaf64e653 KVM: x86: Advertise AMX CPUIDs in subleaf 0x1E.0x1 to userspace.
DMR ISAs enalbing
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Link: https://patch.msgid.link/20251120050720.931449-3-zhao1.liu@intel.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
[ Quanxian Wang: amend commit log ]
Signed-off-by: Quanxian Wang <quanxian.wang@intel.com>
commit 2ff8fb1e65e1a97f75f15935f84b9d2882a49623 upstream.
Bump up the maximum supported AVX10 version and enumerate AVX10.2 to
userspace when it's supported by the host.
Intel AVX10 Version 2 (Intel AVX10.2) includes a suite of new
instructions delivering new AI features and performance, accelerated
media processing, expanded Web Assembly, and Cryptography support, along
with enhancements to existing legacy instructions for completeness and
efficiency, and it is enumerated as version 2 in CPUID 0x24.0x0.EBX[bits
0-7] [1].
AVX10.2 has no current kernel usage and requires no additional host
kernel enabling work (based on AVX10.1 support) and provides no new
VMX controls [2]. Moreover, since AVX10.2 is the superset of AVX10.1,
there's no need to worry about AVX10.1 and AVX10.2 compatibility issues
in KVM.
Therefore, it's safe to advertise AVX10.2 version to userspace directly
if host supports AVX10.2.
[1]: Intel Advanced Vector Extensions 10.2 Architecture Specification
(rev 5.0).
[2]: Note: Since AVX10.2 spec (rev 4.0), it has been declared "AVX10/512
will be used in all Intel products, supporting vector lengths of
128, 256, and 512 in all product lines", and the VMX support (in
earlier revisions) for AVX10/256 guest on AVX10/512 host has been
dropped.
Intel-SIG: commit 2ff8fb1e65e1 KVM: x86: Advertise AVX10.2 CPUID to userspace.
DMR ISAs enalbing
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Link: https://patch.msgid.link/20251120050720.931449-4-zhao1.liu@intel.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
[ Quanxian Wang: amend commit log ]
Signed-off-by: Quanxian Wang <quanxian.wang@intel.com>
commit 062768f426895b958417c85582826e20c44f477c upstream.
Define and advertise AVX10_VNNI_INT CPUID to userspace when it's supported
by the host.
AVX10_VNNI_INT (0x24.0x1.ECX[bit 2]) is a discrete feature bit
introduced on Intel Diamond Rapids, which enumerates the support for
EVEX VPDP* instructions for INT8/INT16 [*].
Since this feature has no actual kernel usages, define it as a KVM-only
feature in reverse_cpuid.h.
Advertise new CPUID subleaf 0x24.0x1 with AVX10_VNNI_INT bit to
userspace for guest use. It's safe since no additional enabling work
is needed in the host kernel.
[*]: Intel Advanced Vector Extensions 10.2 Architecture Specification
(rev 5.0).
Intel-SIG: commit 062768f42689 KVM: x86: Advertise AVX10_VNNI_INT CPUID to userspace.
DMR ISAs enalbing
Tested-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Link: https://patch.msgid.link/20251120050720.931449-5-zhao1.liu@intel.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
[ Quanxian Wang: amend commit log ]
Signed-off-by: Quanxian Wang <quanxian.wang@intel.com>
commit 4ebe2b8cda7e91a30c1cf1d297605682540d4ad9 upstream.
To pick the changes from:
f24ef0093dd8cf60 ("KVM: x86: Advertise MOVRS CPUID to userspace")
f49ecf5e110ab0ed ("x86/cpufeature: Replace X86_FEATURE_SYSENTER32 with X86_FEATURE_SYSFAST32")
db5e82496492b489 ("KVM: SVM: Virtualize and advertise support for ERAPS")
This causes these perf files to be rebuilt and brings some X86_FEATURE
that may be used by:
CC /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
CC /tmp/build/perf/bench/mem-memset-x86-64-asm.o
And addresses this perf build warning:
Warning: Kernel ABI header differences:
diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h
Please see tools/include/uapi/README for further details.
Intel-SIG: commit 4ebe2b8cda7e tools headers x86 cpufeatures: Sync with the kernel sources.
DMR ISAs enalbing
Cc: Amit Shah <amit.shah@amd.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
[ Quanxian Wang: amend commit log ]
Signed-off-by: Quanxian Wang <quanxian.wang@intel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR to enable DMR related ISAs except APX
related ISAs: AVX10.1 AVX10.2 AMXs AVX10_VNNI_INT MOVRS
AMXs: AMX_INT8 AMX_BF16 AMX_COMPLEX AMX_FP16 AMX_FP8 AMX_TF32 AMX_AVX512 AMX_MOVRS
AVX10s: AVX10 AVX10_256 AVX10_512
Testing - PASS please refer below for details
Commits list(6)
4ebe2b8cda7e,tools headers x86 cpufeatures: Sync with the kernel sources,2026-03-04 12:47:03,Arnaldo Carvalho de Melo acme@redhat.com,v7.0-rc4 -- fixes of f24ef0093dd8
062768f42689,KVM: x86: Advertise AVX10_VNNI_INT CPUID to userspace,2026-01-23 10:00:02,Zhao Liu zhao1.liu@intel.com,v7.0-rc1
2ff8fb1e65e1,KVM: x86: Advertise AVX10.2 CPUID to userspace,2026-01-23 10:00:01,Zhao Liu zhao1.liu@intel.com,v7.0-rc1
58cbaf64e653,KVM: x86: Advertise AMX CPUIDs in subleaf 0x1E.0x1 to userspace,2026-01-23 09:59:57,Zhao Liu zhao1.liu@intel.com,v7.0-rc1
f24ef0093dd8,KVM: x86: Advertise MOVRS CPUID to userspace,2026-01-23 09:59:38,Zhao Liu zhao1.liu@intel.com,v7.0-rc1
#depdency 0f 062768f42689 2ff8fb1e65e1
7ea34578aea7,KVM: x86: Replace guts of "governed" features with comprehensive cpu_caps,2024-12-18 14:20:05,Sean Christopherson seanjc@google.com,v6.14-rc1
Note:
1.commit 7ea34578aea7("KVM: x86: Replace guts of "governed" features with comprehensive cpu_caps"), 我们只引进了kvm_only_cpuid_leafs 的修改. 其他的没动。主要是会有更多的dependency
2.commit 4ebe2b8cda7e ("tools headers x86 cpufeatures: Sync with the kernel sources"), 我们只引进了MOVRS的修改，其他的在其他的patches没有touch.
Testing: details
KVM CPUID backport: DMR
Observed: leaf24.0=1 leaf24.1=1 leaf1e.1=1 avx10_bit=1 avx10_ver=2 avx10_vnni_int=0 movrs=1 host_movrs=1 amx_movrs_alias=1
397fa32a7d25 PASS AVX10.1 exposed
62d9450d894e PASS AVX10.2 exposed
2a62ecc5f93f PASS cpu_caps gating is coherent
0a3424753ce9 PASS AMX 0x1E.1 exposed
75ba76fb9e84 PASS AVX10_VNNI_INT correctly not exposed
ee5e250e1282 PASS MOVRS exposure matches host
Summary: pass=6 fail=0
Host cpuid snapshot (for reference only):
CPU:
0x00000007 0x00: eax=0x00000002 ebx=0xf3bfb7ef ecx=0xfb417ffe edx=0xffdc4432
CPU:
0x00000007 0x01: eax=0xccae1df7 ebx=0x00000009 ecx=0x00000003 edx=0x006e4530
CPU:
0x00000024 0x00: eax=0x00000001 ebx=0x00070002 ecx=0x00000000 edx=0x00000000
CPU:
0x00000024 0x01: eax=0x00000001 ebx=0x00000000 ecx=0x00000000 edx=0x00000000
CPU:
0x0000001e 0x01: eax=0x000001df ebx=0x00000000 ecx=0x00000000 edx=0x00000000