From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Zhao Liu <zhao1.liu@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
Chao Gao <chao.gao@intel.com>, John Allen <john.allen@amd.com>,
Babu Moger <babu.moger@amd.com>,
Mathias Krause <minipli@grsecurity.net>,
Dapeng Mi <dapeng1.mi@intel.com>, Zide Chen <zide.chen@intel.com>,
Chenyi Qiang <chenyi.qiang@intel.com>,
Farrah Chen <farrah.chen@intel.com>
Subject: Re: [PATCH v3 05/20] i386/cpu: Make ExtSaveArea store an array of dependencies
Date: Mon, 27 Oct 2025 15:04:29 +0800 [thread overview]
Message-ID: <2d9f489e-dfa5-4bd1-bc7f-62223f81c167@intel.com> (raw)
In-Reply-To: <20251024065632.1448606-6-zhao1.liu@intel.com>
On 10/24/2025 2:56 PM, Zhao Liu wrote:
> Some XSAVE components depend on multiple features. For example, Opmask/
> ZMM_Hi256/Hi16_ZMM depend on avx512f OR avx10, and for CET (which will
> be supported later), cet_u/cet_s will depend on shstk OR ibt.
>
> Although previously there's the special check for the dependencies of
> AVX512F OR AVX10 on their respective XSAVE components (in
> cpuid_has_xsave_feature()), to make the code more general and avoid
> adding more special cases, make ExtSaveArea store a features array
> instead of a single feature, so that it can describe multiple
> dependencies.
>
> Tested-by: Farrah Chen <farrah.chen@intel.com>
> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> ---> target/i386/cpu.c | 71
++++++++++++++++++++++++++++++++++-------------
> target/i386/cpu.h | 9 +++++-
> 2 files changed, 59 insertions(+), 21 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index b9a5a0400dea..cd269d15ce0b 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2020,53 +2020,77 @@ static const X86RegisterInfo32 x86_reg_info_32[CPU_NB_REGS32] = {
> ExtSaveArea x86_ext_save_areas[XSAVE_STATE_AREA_COUNT] = {
> [XSTATE_FP_BIT] = {
> /* x87 FP state component is always enabled if XSAVE is supported */
> - .feature = FEAT_1_ECX, .bits = CPUID_EXT_XSAVE,
> .size = sizeof(X86LegacyXSaveArea) + sizeof(X86XSaveHeader),
> + .features = {
> + { FEAT_1_ECX, CPUID_EXT_XSAVE },
> + },
> },
> [XSTATE_SSE_BIT] = {
> /* SSE state component is always enabled if XSAVE is supported */
> - .feature = FEAT_1_ECX, .bits = CPUID_EXT_XSAVE,
> .size = sizeof(X86LegacyXSaveArea) + sizeof(X86XSaveHeader),
> + .features = {
> + { FEAT_1_ECX, CPUID_EXT_XSAVE },
> + },
> },
> [XSTATE_YMM_BIT] = {
> - .feature = FEAT_1_ECX, .bits = CPUID_EXT_AVX,
> .size = sizeof(XSaveAVX),
> + .features = {
> + { FEAT_1_ECX, CPUID_EXT_AVX },
> + },
> },
> [XSTATE_BNDREGS_BIT] = {
> - .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_MPX,
> .size = sizeof(XSaveBNDREG),
> + .features = {
> + { FEAT_7_0_EBX, CPUID_7_0_EBX_MPX },
> + },
> },
> [XSTATE_BNDCSR_BIT] = {
> - .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_MPX,
> .size = sizeof(XSaveBNDCSR),
> + .features = {
> + { FEAT_7_0_EBX, CPUID_7_0_EBX_MPX },
> + },
> },
> [XSTATE_OPMASK_BIT] = {
> - .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_AVX512F,
> .size = sizeof(XSaveOpmask),
> + .features = {
> + { FEAT_7_0_EBX, CPUID_7_0_EBX_AVX512F },
> + },
> },
> [XSTATE_ZMM_Hi256_BIT] = {
> - .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_AVX512F,
> .size = sizeof(XSaveZMM_Hi256),
> + .features = {
> + { FEAT_7_0_EBX, CPUID_7_0_EBX_AVX512F },
> + },
> },
> [XSTATE_Hi16_ZMM_BIT] = {
> - .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_AVX512F,
> .size = sizeof(XSaveHi16_ZMM),
> + .features = {
> + { FEAT_7_0_EBX, CPUID_7_0_EBX_AVX512F },
> + },
> },
> [XSTATE_PKRU_BIT] = {
> - .feature = FEAT_7_0_ECX, .bits = CPUID_7_0_ECX_PKU,
> .size = sizeof(XSavePKRU),
> + .features = {
> + { FEAT_7_0_ECX, CPUID_7_0_ECX_PKU },
> + },
> },
> [XSTATE_ARCH_LBR_BIT] = {
> - .feature = FEAT_7_0_EDX, .bits = CPUID_7_0_EDX_ARCH_LBR,
> .size = sizeof(XSaveArchLBR),
> + .features = {
> + { FEAT_7_0_EDX, CPUID_7_0_EDX_ARCH_LBR },
> + },
> },
> [XSTATE_XTILE_CFG_BIT] = {
> - .feature = FEAT_7_0_EDX, .bits = CPUID_7_0_EDX_AMX_TILE,
> .size = sizeof(XSaveXTILECFG),
> + .features = {
> + { FEAT_7_0_EDX, CPUID_7_0_EDX_AMX_TILE },
> + },
> },
> [XSTATE_XTILE_DATA_BIT] = {
> - .feature = FEAT_7_0_EDX, .bits = CPUID_7_0_EDX_AMX_TILE,
> .size = sizeof(XSaveXTILEDATA),
> + .features = {
> + { FEAT_7_0_EDX, CPUID_7_0_EDX_AMX_TILE },
> + },
> },
> };
>
> @@ -7137,10 +7161,13 @@ static const char *x86_cpu_feature_name(FeatureWord w, int bitnr)
> if (w == FEAT_XSAVE_XCR0_LO || w == FEAT_XSAVE_XCR0_HI) {
> int comp = (w == FEAT_XSAVE_XCR0_HI) ? bitnr + 32 : bitnr;
>
> - if (comp < ARRAY_SIZE(x86_ext_save_areas) &&
> - x86_ext_save_areas[comp].bits) {
> - w = x86_ext_save_areas[comp].feature;
> - bitnr = ctz32(x86_ext_save_areas[comp].bits);
> + if (comp < ARRAY_SIZE(x86_ext_save_areas)) {
> + /* Present the first feature as the default. */
> + const FeatureMask *fm = &x86_ext_save_areas[comp].features[0];
It doesn't look right to me.
E.g., when users are requesting IBT, thus CET_U and CET_S, they might
get "shstk" not avaiable.
> + if (fm->mask != 0) {
Nit: if (fm->mask) is enough
> + w = fm->index;
> + bitnr = ctz32(fm->mask);
> + }
> }
> }
>
> @@ -8610,11 +8637,15 @@ static bool cpuid_has_xsave_feature(CPUX86State *env, const ExtSaveArea *esa)
> return false;
> }
>
> - if (env->features[esa->feature] & esa->bits) {
> - return true;
> + for (int i = 0; i < ARRAY_SIZE(esa->features); i++) {
> + if (env->features[esa->features[i].index] & esa->features[i].mask) {
> + return true;
> + }
> }
> - if (esa->feature == FEAT_7_0_EBX && esa->bits == CPUID_7_0_EBX_AVX512F
> - && (env->features[FEAT_7_1_EDX] & CPUID_7_1_EDX_AVX10)) {
> +
> + if (esa->features[0].index == FEAT_7_0_EBX &&
> + esa->features[0].mask == CPUID_7_0_EBX_AVX512F &&
> + (env->features[FEAT_7_1_EDX] & CPUID_7_1_EDX_AVX10)) {
> return true;
> }
>
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index ac527971d8cd..6537affcf067 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1769,9 +1769,16 @@ QEMU_BUILD_BUG_ON(sizeof(XSaveXTILECFG) != 0x40);
> QEMU_BUILD_BUG_ON(sizeof(XSaveXTILEDATA) != 0x2000);
>
> typedef struct ExtSaveArea {
> - uint32_t feature, bits;
> uint32_t offset, size;
> uint32_t ecx;
> + /*
> + * The dependencies in the array work as OR relationships, which
> + * means having just one of those features is enough.
> + *
> + * At most two features are sharing the same xsave area.
> + * Number of features can be adjusted if necessary.
> + */
> + const FeatureMask features[2];
> } ExtSaveArea;
>
> #define XSAVE_STATE_AREA_COUNT (XSTATE_XTILE_DATA_BIT + 1)
next prev parent reply other threads:[~2025-10-27 7:05 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 6:56 [PATCH v3 00/20] i386: Support CET for KVM Zhao Liu
2025-10-24 6:56 ` [PATCH v3 01/20] linux-headers: Update to v6.18-rc2 Zhao Liu
2025-10-24 6:56 ` [PATCH v3 02/20] i386/cpu: Clean up indent style of x86_ext_save_areas[] Zhao Liu
2025-10-27 5:47 ` Xiaoyao Li
2025-10-30 15:11 ` Zhao Liu
2025-10-24 6:56 ` [PATCH v3 03/20] i386/cpu: Clean up arch lbr xsave struct and comment Zhao Liu
2025-10-24 18:20 ` Chen, Zide
2025-10-27 6:08 ` Xiaoyao Li
2025-10-24 6:56 ` [PATCH v3 04/20] i386/cpu: Reorganize arch lbr structure definitions Zhao Liu
2025-10-24 18:20 ` Chen, Zide
2025-10-27 6:22 ` Xiaoyao Li
2025-10-24 6:56 ` [PATCH v3 05/20] i386/cpu: Make ExtSaveArea store an array of dependencies Zhao Liu
2025-10-27 7:04 ` Xiaoyao Li [this message]
2025-10-27 10:09 ` Zhao Liu
2025-10-24 6:56 ` [PATCH v3 06/20] i386/cpu: Add avx10 dependency for Opmask/ZMM_Hi256/Hi16_ZMM Zhao Liu
2025-10-27 7:05 ` Xiaoyao Li
2025-10-24 6:56 ` [PATCH v3 07/20] i386/cpu: Reorganize dependency check for arch lbr state Zhao Liu
2025-10-24 18:21 ` Chen, Zide
2025-10-27 7:40 ` Xiaoyao Li
2025-10-27 10:12 ` Zhao Liu
2025-10-27 11:15 ` Xiaoyao Li
2025-10-30 15:40 ` Zhao Liu
2025-10-24 6:56 ` [PATCH v3 08/20] i386/cpu: Drop pmu check in CPUID 0x1C encoding Zhao Liu
2025-10-24 18:21 ` Chen, Zide
2025-10-27 7:51 ` Xiaoyao Li
2025-10-27 11:01 ` Zhao Liu
2025-10-24 6:56 ` [PATCH v3 09/20] i386/cpu: Fix supervisor xstate initialization Zhao Liu
2025-10-27 7:55 ` Xiaoyao Li
2025-10-27 10:13 ` Zhao Liu
2025-10-24 6:56 ` [PATCH v3 10/20] i386/cpu: Add missing migratable xsave features Zhao Liu
2025-10-27 8:42 ` Xiaoyao Li
2025-10-27 10:19 ` Zhao Liu
2025-10-27 11:18 ` Zhao Liu
2025-10-27 12:02 ` Xiaoyao Li
2025-10-30 15:56 ` Zhao Liu
2025-11-05 10:39 ` Xiaoyao Li
2025-10-27 11:36 ` Zhao Liu
2025-10-24 6:56 ` [PATCH v3 11/20] i386/cpu: Enable xsave support for CET states Zhao Liu
2025-10-28 8:00 ` Xiaoyao Li
2025-10-29 4:58 ` Chao Gao
2025-10-30 4:29 ` Xiaoyao Li
2025-10-30 16:39 ` Zhao Liu
2025-10-24 6:56 ` [PATCH v3 12/20] i386/cpu: Add CET support in CR4 Zhao Liu
2025-10-28 2:04 ` Chenyi Qiang
2025-10-30 15:57 ` Zhao Liu
2025-10-24 6:56 ` [PATCH v3 13/20] i386/kvm: Add save/load support for CET MSRs Zhao Liu
2025-10-24 6:56 ` [PATCH v3 14/20] i386/kvm: Add save/load support for KVM_REG_GUEST_SSP Zhao Liu
2025-10-28 8:21 ` Xiaoyao Li
2025-10-24 6:56 ` [PATCH v3 15/20] i386/machine: Add vmstate for cet-ss and cet-ibt Zhao Liu
2025-10-28 8:29 ` Xiaoyao Li
2025-10-30 16:04 ` Zhao Liu
2025-11-05 10:41 ` Xiaoyao Li
2025-10-24 6:56 ` [PATCH v3 16/20] i386/cpu: Mark cet-u & cet-s xstates as migratable Zhao Liu
2025-10-27 11:34 ` Zhao Liu
2025-10-29 6:13 ` Chao Gao
2025-10-29 6:10 ` Chao Gao
2025-10-30 16:09 ` Zhao Liu
2025-10-24 6:56 ` [PATCH v3 17/20] i386/cpu: Advertise CET related flags in feature words Zhao Liu
2025-10-28 8:33 ` Xiaoyao Li
2025-10-24 6:56 ` [PATCH v3 18/20] i386/cpu: Enable cet-ss & cet-ibt for supported CPU models Zhao Liu
2025-10-28 8:34 ` Xiaoyao Li
2025-10-24 6:56 ` [PATCH v3 19/20] i386/tdx: Fix missing spaces in tdx_xfam_deps[] Zhao Liu
2025-10-28 8:37 ` Xiaoyao Li
2025-10-24 6:56 ` [PATCH v3 20/20] i386/tdx: Add CET SHSTK/IBT into the supported CPUID by XFAM Zhao Liu
2025-10-28 8:55 ` Xiaoyao Li
2025-10-30 16:07 ` Zhao Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d9f489e-dfa5-4bd1-bc7f-62223f81c167@intel.com \
--to=xiaoyao.li@intel.com \
--cc=babu.moger@amd.com \
--cc=chao.gao@intel.com \
--cc=chenyi.qiang@intel.com \
--cc=dapeng1.mi@intel.com \
--cc=farrah.chen@intel.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=minipli@grsecurity.net \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=zhao1.liu@intel.com \
--cc=zide.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).