On Tue, Mar 04, 2025 at 02:20:31PM -0800, Dave Hansen wrote:
>On 11/26/24 02:17, Chao Gao wrote:
>> When granting userspace or a KVM guest access to an xfeature, preserve the
>> entity's existing supervisor and software-defined permissions as tracked
>> by __state_perm, i.e. use __state_perm to track *all* permissions even
>> though all supported supervisor xfeatures are granted to all FPUs and
>> FPU_GUEST_PERM_LOCKED disallows changing permissions.
>
>Should we document what __state_perm contains either in
>fpu_state_perm or xstate_get_group_perm()?
Yes. I think we should document it. Will apply this change:
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index da6583a1c0a2..93481583dc85 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -417,9 +417,11 @@ struct fpu_state_perm {
/*
* @__state_perm:
*
- * This bitmap indicates the permission for state components, which
- * are available to a thread group. The permission prctl() sets the
- * enabled state bits in thread_group_leader()->thread.fpu.
+ * This bitmap indicates the permission for state components
+ * available to a thread group, including both user and supervisor
+ * components and software-defined bits like FPU_GUEST_PERM_LOCKED.
+ * The permission prctl() sets the enabled state bits in
+ * thread_group_leader()->thread.fpu.
*
* All run time operations use the per thread information in the
* currently active fpu.fpstate which contains the xfeature masks
>
>Either way:
>
>Acked-by: Dave Hansen <dave.hansen@xxxxxxxxx>
