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

[Chang S. Bae]

On 4/30/2025 9:20 AM, Sean Christopherson wrote:
> On Wed, Apr 30, 2025, Rick P Edgecombe wrote:
> > On Wed, 2025-04-30 at 08:01 -0700, Chang S. Bae wrote:
> > > On 4/28/2025 8:36 PM, Edgecombe, Rick P wrote:
> > > > KVM_GET_XSAVE is part of KVM's API. It uses fields configured in struct
> > > > fpu_guest. If fpu_user_cfg.default_features changes value (in the current code)
> > > > it would change KVM's uABI.
> > >
> > > Not quite. The ABI reflects the XSAVE format directly. The XSAVE header
> > > indicates which feature states are present, so while the _contents_ of
> > > the buffer may vary depending on the feature set, the _format_ itself
> > > remains unchanged. That doesn't constitute a uABI change.
> >
> > Heh, ok sure.
>
> Hmm, it's a valid point that format isn't changing, and that host userspace and
> guests will inevitably have different state in the XSAVE buffer.
>
> That said, it's still an ABI change in the sense that once support for CET_S is
> added, userspace can rely on KVM_{G,S}ET_XSAVE(2) to save/restore CET_S state,
> and dropping that support would clearly break userspace.

I think my comment was specifically in response to this statement "if 
fpu_user_cfg.default_features changes value," which I took to mean 
changes limited to user features.

Diverging guest user features wasn’t something I intended here -- 
although I briefly considered MPX but dropped it due to complexity:

https://lore.kernel.org/lkml/2ac2d1e7-d04b-443a-8fff-7aa3f436dcce@xxxxxxxxx/

At this point, I think the reaction here speaks for itself. If adding 
those two fields leads to confusion or demands fatty code comment, the 
net benefit goes negative.

So yes, overall, let's just reference fpu_guest_cfg directly as-is.

Thanks,
Chang