On 5/7/24 15:57, Sean Christopherson wrote: >> 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. Yes. Silly thinko/typo on my part. > 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); Yeah, that would make a lot of sense. We could add a more generic #define for it later if another feature gets added like this.
