Re: [PATCH v8 6/6] x86/fpu/xstate: Add CET supervisor xfeature support as a guest-only feature

[John Allen <john.allen@amd.com>]

On Thu, May 22, 2025 at 08:10:09AM -0700, Chao Gao wrote:
> From: Yang Weijiang <weijiang.yang@intel.com>
> 
> == Background ==
> 
> CET defines two register states: CET user, which includes user-mode control
> registers, and CET supervisor, which consists of shadow-stack pointers for
> privilege levels 0-2.
> 
> Current kernels disable shadow stacks in kernel mode, making the CET
> supervisor state unused and eliminating the need for context switching.
> 
> == Problem ==
> 
> To virtualize CET for guests, KVM must accurately emulate hardware
> behavior. A key challenge arises because there is no CPUID flag to indicate
> that shadow stack is supported only in user mode. Therefore, KVM cannot
> assume guests will not enable shadow stacks in kernel mode and must
> preserve the CET supervisor state of vCPUs.
> 
> == Solution ==
> 
> An initial proposal to manually save and restore CET supervisor states
> using raw RDMSR/WRMSR in KVM was rejected due to performance concerns and
> its impact on KVM's ABI. Instead, leveraging the kernel's FPU
> infrastructure for context switching was favored [1].
> 
> The main question then became whether to enable the CET supervisor state
> globally for all processes or restrict it to vCPU processes. This decision
> involves a trade-off between a 24-byte XSTATE buffer waste for all non-vCPU
> processes and approximately 100 lines of code complexity in the kernel [2].
> The agreed approach is to first try this optimal solution [3], i.e.,
> restricting the CET supervisor state to guest FPUs only and eliminating
> unnecessary space waste.
> 
> The guest-only xfeature infrastructure has already been added. Now,
> introduce CET supervisor xstate support as the first guest-only feature
> to prepare for the upcoming CET virtualization in KVM.
> 
> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>

Reviewed-by: John Allen <john.allen@amd.com>