Re: [PATCH v5 3/7] x86/fpu/xstate: Differentiate default features for host and guest FPUs

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Fri, 2025-04-25 at 16:24 +0800, Chao Gao wrote:
> > 
> > In the later patches, it doesn't seem to change the "user" parts. These
> > configurations end up controlling the default size and features that gets
> > copied
> > to userspace in KVM_SET_XSAVE. I guess today there is only one default size
> > and
> > feature set for xstate copied to userspace. The suggestion from Chang was
> > that
> > it makes the code more readable, but it seems like it also breaks apart a
> > unified concept for no functional benefit.
> 
> In the future, the feature and size of the uABI buffer for guest FPUs may
> differ from those of non-guest FPUs. Sean rejected the idea of
> saving/restoring
> CET_S xstate in KVM partly because:
> 
>  :Especially because another big negative is that not utilizing XSTATE bleeds
> into
>  :KVM's ABI.  Userspace has to be told to manually save+restore MSRs instead
> of just
>  :letting KVM_{G,S}ET_XSAVE handle the state.

Hmm, interesting. I guess there are two things.
1. Should CET_S be part of KVM_GET_XSAVE instead of via MSRs ioctls? It never
was in the KVM CET patches.
2. A feature mask far away in the FPU code controls KVM's xsave ABI.

For (1), does any userspace depend on their not being supervisor features? (i.e.
tries to restore the guest FPU for emulation or something). There probably are
some advantages to keeping supervisor features out of it, or at least a separate
ioctl. (2) is an existing problem. But if we think KVM should have its own
feature set of bits for ABI purposes, it seems like maybe it should have some
dedicated consideration. 

I'd think we should not try to address it in this series. Let's stick to what
the current CET KVM series needs. Changing KVM_GET_XSAVE behavior or cleanup
could be a separate series.

>   And that will create a bit of a
>  :snafu if Linux does gain support for SSS.
> 
> *: https://lore.kernel.org/kvm/ZM1jV3UPL0AMpVDI@google.com/

I chatted with Xin about this a few weeks ago. It sounds like FRED bare metal
SSS will not need CET_S state, but it wasn't 100% clear.

>