> From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Sent: Wednesday, January 5, 2022 9:07 PM
>
> On 1/5/22 13:35, Yang Zhong wrote:
> > +int fpu_enable_guest_xfd_features(struct fpu_guest *guest_fpu, u64
> xfeatures)
> > +{
> > + lockdep_assert_preemption_enabled();
> > +
>
> The old fpu_update_guest_perm_features(guest_fpu) is equivalent to
>
> fpu_enable_guest_xfd_features(guest_fpu, guest_fpu->perm);
>
> Missing doc comment:
>
> /*
> * fpu_enable_guest_xfd_features - Enable xfeatures according to guest
> perm
> * @guest_fpu: Pointer to the guest FPU container
> * @xfeatures: Features requested by guest CPUID
> *
> * Enable all dynamic xfeatures according to guest perm and requested
> CPUID.
> * Invoked if the caller wants to conservatively expand fpstate buffer instead
> * of waiting until XCR0 or XFD MSR is written.
> *
> * Return: 0 on success, error code otherwise
> */
It's not equivalent. The old interface enables all xfeatures allowed by
guest perm while the new one just enables feature bits according to
the caller request. It also becomes a more general interface instead of
being only for conservative expansion. Since both points in the old
comment don't hold now and this function is obvious, we didn't put
a comment here (on par with other KVM helpers in that block).
If still necessary we could add one like below:
/*
* fpu_enable_guest_xfd_features - Enable xfeatures for guest fpu container
* @guest_fpu: Pointer to the guest FPU container
* @xfeatures: Features requested by the caller
*
* Enable dynamic xfeatures and expand guest fpstate buffer accordingly.
* KVM should call this function before the requested xfeatures are used
* by the guest.
*
* Return: 0 on success, error code otherwise
*/
>
> Also, the check for 32-bit is slightly imprecise:
>
> /* Dynamic xfeatures are not supported with 32-bit kernels. */
> if (!IS_ENABLED(CONFIG_X86_64))
> - return 0;
> + return -EINVAL;
>
> since we only get here with xfeatures != 0 (if it compiles, just removing
> the IS_ENABLED check altogether would be even better). With these changes,
>
> Reviewed-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
>
> Thanks,
>
> Paolo
