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