From: Peter Fang <peter.fang@intel.com>

Add the APX xfeature bit to the list of supported XCR0 components and
expose the APX feature to guests. Update the maximum supported CPUID leaf
to 0x29 to include the APX leaf. On SVM systems, ensure that the feature
is not advertised as EGPR support is not yet supported.

No APX sub-features are enumerated yet. Those will be exposed in a
separate patch.

Signed-off-by: Peter Fang <peter.fang@intel.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
---
V1 -> V2: Exclude the APX CPUID definition as patch8 includes it now
---
 arch/x86/kvm/cpuid.c   | 8 +++++++-
 arch/x86/kvm/svm/svm.c | 8 ++++++++
 arch/x86/kvm/x86.c     | 3 ++-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 88a5426674a1..5431e31a4851 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -1038,6 +1038,7 @@ void kvm_set_cpu_caps(void)
 		F(AVX_VNNI_INT16),
 		F(PREFETCHITI),
 		F(AVX10),
+		SCATTERED_F(APX),
 	);
 
 	kvm_cpu_cap_init(CPUID_7_2_EDX,
@@ -1401,7 +1402,7 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
 	switch (function) {
 	case 0:
 		/* Limited to the highest leaf implemented in KVM. */
-		entry->eax = min(entry->eax, 0x24U);
+		entry->eax = min(entry->eax, 0x29U);
 		break;
 	case 1:
 		cpuid_entry_override(entry, CPUID_1_EDX);
@@ -1646,6 +1647,11 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
 		entry->edx = 0;
 		break;
 	}
+	case 0x29: {
+		/* No APX sub-features are supported yet */
+		entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
+		break;
+	}
 	case KVM_CPUID_SIGNATURE: {
 		const u32 *sigptr = (const u32 *)KVM_SIGNATURE;
 		entry->eax = KVM_CPUID_FEATURES;
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index a06e5a24b808..9c76ea7a4231 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -5284,6 +5284,14 @@ static __init void svm_set_cpu_caps(void)
 	 */
 	kvm_cpu_cap_clear(X86_FEATURE_BUS_LOCK_DETECT);
 	kvm_cpu_cap_clear(X86_FEATURE_MSR_IMM);
+
+	/*
+	 * If the APX xfeature bit is not supported, meaning that VMCB
+	 * support for EGPRs is unavailable, then the APX feature should
+	 * not be exposed to the guest.
+	 */
+	if (!(kvm_caps.supported_xcr0 & XFEATURE_MASK_APX))
+		kvm_cpu_cap_clear(X86_FEATURE_APX);
 }
 
 static __init int svm_hardware_setup(void)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 189a03483d03..67b3312ab737 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -214,7 +214,8 @@ static DEFINE_PER_CPU(struct kvm_user_return_msrs, user_return_msrs);
 #define KVM_SUPPORTED_XCR0     (XFEATURE_MASK_FP | XFEATURE_MASK_SSE \
 				| XFEATURE_MASK_YMM | XFEATURE_MASK_BNDREGS \
 				| XFEATURE_MASK_BNDCSR | XFEATURE_MASK_AVX512 \
-				| XFEATURE_MASK_PKRU | XFEATURE_MASK_XTILE)
+				| XFEATURE_MASK_PKRU | XFEATURE_MASK_XTILE \
+				| XFEATURE_MASK_APX)
 
 #define XFEATURE_MASK_CET_ALL	(XFEATURE_MASK_CET_USER | XFEATURE_MASK_CET_KERNEL)
 /*
-- 
2.51.0

+ Rick and Binbin

On 1/13/2026 7:54 AM, Chang S. Bae wrote:
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 189a03483d03..67b3312ab737 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -214,7 +214,8 @@ static DEFINE_PER_CPU(struct kvm_user_return_msrs, user_return_msrs);
>   #define KVM_SUPPORTED_XCR0     (XFEATURE_MASK_FP | XFEATURE_MASK_SSE \
>   				| XFEATURE_MASK_YMM | XFEATURE_MASK_BNDREGS \
>   				| XFEATURE_MASK_BNDCSR | XFEATURE_MASK_AVX512 \
> -				| XFEATURE_MASK_PKRU | XFEATURE_MASK_XTILE)
> +				| XFEATURE_MASK_PKRU | XFEATURE_MASK_XTILE \
> +				| XFEATURE_MASK_APX)
>   

Not any intention of this patch, but this change eventually allows the 
userspace to expose APX to TDX guests.

Without any mentioning of TDX APX tests and validation like the one for 
CET[1], I think it's unsafe to allow it for TDX guests. E.g., the worst 
case would be KVM might need extra handling to keep host's 
states/functionalities correct once TD guest is able to manage APX.

I'm thinking maybe we need introduce a supported mask, 
KVM_SUPPORTED_TD_XFAM, like KVM_SUPPORTED_TD_ATTRS. So that any new XFAM 
related feature for TD needs the explicit enabling in KVM, and people 
work on the new XSAVE related feature enabling for normal VMs don't need 
to worry about the potential TDX impact.

[1] 
https://lore.kernel.org/all/ecaaef65cf1cd90eb8f83e6a53d9689c8b0b9a22.camel@intel.com/

On Mon, 2026-01-19 at 13:55 +0800, Xiaoyao Li wrote:
> + Rick and Binbin
> 
> On 1/13/2026 7:54 AM, Chang S. Bae wrote:
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 189a03483d03..67b3312ab737 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -214,7 +214,8 @@ static DEFINE_PER_CPU(struct kvm_user_return_msrs, user_return_msrs);
> >    #define KVM_SUPPORTED_XCR0     (XFEATURE_MASK_FP | XFEATURE_MASK_SSE \
> >    				| XFEATURE_MASK_YMM | XFEATURE_MASK_BNDREGS \
> >    				| XFEATURE_MASK_BNDCSR | XFEATURE_MASK_AVX512 \
> > -				| XFEATURE_MASK_PKRU | XFEATURE_MASK_XTILE)
> > +				| XFEATURE_MASK_PKRU | XFEATURE_MASK_XTILE \
> > +				| XFEATURE_MASK_APX)
> >    
> 
> Not any intention of this patch, but this change eventually allows the 
> userspace to expose APX to TDX guests.
> 
> Without any mentioning of TDX APX tests and validation like the one for 
> CET[1], I think it's unsafe to allow it for TDX guests.
> 

That was an especially odd one.

>  E.g., the worst 
> case would be KVM might need extra handling to keep host's 
> states/functionalities correct once TD guest is able to manage APX.
> 
> I'm thinking maybe we need introduce a supported mask, 
> KVM_SUPPORTED_TD_XFAM, like KVM_SUPPORTED_TD_ATTRS. So that any new XFAM 
> related feature for TD needs the explicit enabling in KVM, and people 
> work on the new XSAVE related feature enabling for normal VMs don't need 
> to worry about the potential TDX impact.

We might need it. But in general, I agree KVM enabling for new features needs to
consider the TDX impact now. For APX, it looks like we don't need to add a new
type of supported feature tracking because the TDX APX arch is public.

Chang, let's circle back internally and figure out who owns what.

> 
> [1] 
> https://lore.kernel.org/all/ecaaef65cf1cd90eb8f83e6a53d9689c8b0b9a22.camel@intel.com/

On 1/20/2026 10:07 AM, Edgecombe, Rick P wrote:
> On Mon, 2026-01-19 at 13:55 +0800, Xiaoyao Li wrote:   
>>
>> Not any intention of this patch, but this change eventually allows the
>> userspace to expose APX to TDX guests.
>>
>> Without any mentioning of TDX APX tests and validation like the one for
>> CET[1], I think it's unsafe to allow it for TDX guests.

My original assumption was like what I just mentioned in the RFC cover:

   The specification deliberately scopes out some areas. For example,
   Sections 3.1.4.4.2–7 note that initialization and reset behaviors
   follow existing XSTATE conventions.

With there in 3.1.4.4.2 Intel® TDX,

   Intel® TDX has an XCR0-derived interface called TDCS.XFAM. Bits in
   XFAM act as an opt-in for state and ISA controls. Therefore,
   XFAM[APX_F] acts as a control for enabling Intel® APX within Trust
   Domains (or TDs), and the XFAM settings are established at TD INIT
   (TDH.TD.INIT).

Conceptually, APX enablement for TDX could be explicitly gated, which 
helps to narrow the scope of the KVM changes (perhaps, at least for the 
early review).

*However*, once the APX bit is set in supported_xcr0, it can flow into 
XFAM through the code path as:

tdx_get_supported_xfam(...)
{
	u64 val = kvm_caps.supported_xcr0 | kvm_caps.supported_xss;

	if ((val & td_conf->xfam_fixed1) != td_conf->xfam_fixed1)
		return 0;

	val &= td_conf->xfam_fixed0;

	return val;
}

So I agree that, in the current codebase, whoever updates the KVM-side 
bitmask should ensure that TDX guests are okay with it. I also now 
understand the idea that TDX guests are yet another guest type, which is 
under the impact of whatever kvm_cap changes.

>>
> 
> That was an especially odd one.
> 
>>   E.g., the worst
>> case would be KVM might need extra handling to keep host's
>> states/functionalities correct once TD guest is able to manage APX.
>>
>> I'm thinking maybe we need introduce a supported mask,
>> KVM_SUPPORTED_TD_XFAM, like KVM_SUPPORTED_TD_ATTRS. So that any new XFAM
>> related feature for TD needs the explicit enabling in KVM, and people
>> work on the new XSAVE related feature enabling for normal VMs don't need
>> to worry about the potential TDX impact.
> 
> We might need it. But in general, I agree KVM enabling for new features needs to
> consider the TDX impact now. For APX, it looks like we don't need to add a new
> type of supported feature tracking because the TDX APX arch is public.
> 
> Chang, let's circle back internally and figure out who owns what.

I'd come back here with positive TDX test results once available. For 
now, I would leave additional guarding or geting outside of this 
enabling scope.

Thanks,
Chang

On Tue, 2026-01-20 at 12:50 -0800, Chang S. Bae wrote:
> > Chang, let's circle back internally and figure out who owns what.
> 
> I'd come back here with positive TDX test results once available. For 
> now, I would leave additional guarding or geting outside of this 
> enabling scope.

After some discussion, I think this will be addressed with future TDX module
opt-in changes. So we can skip the TDX testing for this series. Thanks.