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 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.

> 
> > It should be simple. Two new configuration fields are added in this patch that
> > match the existing concept and values of existing configurations fields. Per
> > Sean, there are no plans to have them diverge. So why add them. 
> 
> I'm fine with dropping them -- as long as the resulting code remains 
> clear and avoids unnecessary complexity around VCPU allocation.
> 
> Here are some of the considerations that led me to suggest them in the 
> first place:
> 
>   * The guest-only feature model should be established in a clean and
>     structured way.
>   * The initialization logic should stay explicit -- especially to make
>     it clear what constitutes guest features, even when they match host
>     features. That naturally led to introducing a dedicated data
>     structure.
>   * Since the VCPU FPU container includes struct fpstate, it felt
>     appropriate to mirror relevant fields where useful.
>   * Including user_size and user_xfeatures made the VCPU allocation logic
>     more straightforward and self-contained.
> 
> And to clarify -- this addition doesn’t necessarily imply divergence 
> from fpu_guest_cfg. Its usage is local to setting up the guest fpstate, 
> and nothing more.

I'd like to close this out. I see there there is currently one concept of user
features and size, and per Sean, KVM intends to stay consistent with the rest of
the kernel - leaving it at one concept. This was new info since you suggested
the fields. So why don't you propose a resolution here and we'll just go with
it.