Re: [PATCH v10 04/27] x86/fpu/xstate: Introduce XFEATURE_MASK_KERNEL_DYNAMIC xfeature set

From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Yang Weijiang <weijiang.yang@intel.com>,
	pbonzini@redhat.com, x86@kernel.org,  kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, peterz@infradead.org,
	 chao.gao@intel.com, rick.p.edgecombe@intel.com,
	mlevitsk@redhat.com,  john.allen@amd.com
Subject: Re: [PATCH v10 04/27] x86/fpu/xstate: Introduce XFEATURE_MASK_KERNEL_DYNAMIC xfeature set
Date: Tue, 7 May 2024 15:57:55 -0700	[thread overview]
Message-ID: <Zjqx8-ZPyB--6Eys@google.com> (raw)
In-Reply-To: <893ac578-baaf-4f4f-96ee-e012dfc073a8@intel.com>

On Thu, May 02, 2024, Dave Hansen wrote:
> On 5/1/24 11:45, Sean Christopherson wrote:
> > On Sun, Feb 18, 2024, Yang Weijiang wrote:
> >> Define a new XFEATURE_MASK_KERNEL_DYNAMIC mask to specify the features
> > I still don't understand why this is being called DYNAMIC.  CET_SS isn't dynamic,
> > as KVM is _always_ allowed to save/restore CET_SS, i.e. whether or not KVM can
> > expose CET_SS to a guest is a static, boot-time decision.  Whether or not a guest
> > XSS actually enables CET_SS is "dynamic", but that's true of literally every
> > xfeature in XCR0 and XSS.
> > 
> > XFEATURE_MASK_XTILE_DATA is labeled as dynamic because userspace has to explicitly
> > request that XTILE_DATA be enabled, and thus whether or not KVM is allowed to
> > expose XTILE_DATA to the guest is a dynamic, runtime decision.
> > 
> > So IMO, the umbrella macro should be XFEATURE_MASK_KERNEL_GUEST_ONLY.
> 
> Here's how I got that naming.  First, "static" features are always
> there.  "Dynamic" features might or might not be there.  I was also much
> more focused on what's in the XSAVE buffer than on the enabling itself,
> which are _slightly_ different.

Ah, and CET_KERNEL will be '0' in XSTATE_BV for non-guest buffers, but '1' for
guest buffers.

> Then, it's a matter of whether the feature is user or supervisor.  The
> kernel might need new state for multiple reasons.  Think of LBR state as
> an example.  The kernel might want LBR state around for perf _or_ so it
> can be exposed to a guest.
> 
> I just didn't want to tie it to "GUEST" too much in case we have more of
> these things come along that get used for things unrelated to KVM.
> Obviously, at this point, we've only got one and KVM is the only user so
> the delta that I was worried about doesn't actually exist.
> 
> So I still prefer calling it "KERNEL" over "GUEST".  But I also don't
> feel strongly about it and I've said my peace.  I won't NAK it one way
> or the other.

I assume you mean "DYNAMIC" over "GUEST"?  I'm ok with DYNAMIC, reflecting the
impact on each buffer makes sense.

My one request would be to change the WARN in os_xsave() to fire on CET_KERNEL,
not KERNEL_DYNAMIC, because it's specifically CET_KERNEL that is guest-only.
Future dynamic xfeatures could be guest-only, but they could also be dynamic for
some completely different reason.  That was my other hang-up with "DYNAMIC";
as-is, os_xsave() implies that it really truly is GUEST_ONLY.

diff --git a/arch/x86/kernel/fpu/xstate.h b/arch/x86/kernel/fpu/xstate.h
index 83ebf1e1cbb4..2a1ff49ccfd5 100644
--- a/arch/x86/kernel/fpu/xstate.h
+++ b/arch/x86/kernel/fpu/xstate.h
@@ -185,8 +185,7 @@ static inline void os_xsave(struct fpstate *fpstate)
        WARN_ON_FPU(!alternatives_patched);
        xfd_validate_state(fpstate, mask, false);
 
-       WARN_ON_FPU(!fpstate->is_guest &&
-                   (mask & XFEATURE_MASK_KERNEL_DYNAMIC));
+       WARN_ON_FPU(!fpstate->is_guest && (mask & XFEATURE_MASK_CET_KERNEL));
 
        XSTATE_XSAVE(&fpstate->regs.xsave, lmask, hmask, err);
