Re: [PATCH v2 14/16] KVM: x86: Expose APX foundational feature bit to guests

["Edgecombe, Rick P" <rick.p.edgecombe@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/