kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: <tglx@linutronix.de>, <x86@kernel.org>, <seanjc@google.com>,
	<pbonzini@redhat.com>, <linux-kernel@vger.kernel.org>,
	<kvm@vger.kernel.org>, <peterz@infradead.org>,
	<rick.p.edgecombe@intel.com>, <mlevitsk@redhat.com>,
	<weijiang.yang@intel.com>, <john.allen@amd.com>
Subject: Re: [PATCH v2 1/6] x86/fpu/xstate: Always preserve non-user xfeatures/flags in __state_perm
Date: Wed, 5 Mar 2025 16:25:29 +0800	[thread overview]
Message-ID: <Z8gKeVN83omngleo@intel.com> (raw)
In-Reply-To: <ce5e2f44-144b-47bd-9f7e-02f61abed76a@intel.com>

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@intel.com>

  reply	other threads:[~2025-03-05  8:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26 10:17 [PATCH v2 0/6] Introduce CET supervisor state support Chao Gao
2024-11-26 10:17 ` [PATCH v2 1/6] x86/fpu/xstate: Always preserve non-user xfeatures/flags in __state_perm Chao Gao
2025-03-04 22:20   ` Dave Hansen
2025-03-05  8:25     ` Chao Gao [this message]
2024-11-26 10:17 ` [PATCH v2 2/6] x86/fpu/xstate: Add CET supervisor mode state support Chao Gao
2025-03-04 22:26   ` Dave Hansen
2025-03-05  8:32     ` Chao Gao
2024-11-26 10:17 ` [PATCH v2 3/6] x86/fpu/xstate: Introduce XFEATURE_MASK_KERNEL_DYNAMIC xfeature set Chao Gao
2025-03-04 22:37   ` Dave Hansen
2025-03-05  8:43     ` Chao Gao
2024-11-26 10:17 ` [PATCH v2 4/6] x86/fpu/xstate: Introduce fpu_guest_cfg for guest FPU configuration Chao Gao
2025-03-04 22:50   ` Dave Hansen
2025-03-05  8:57     ` Chao Gao
2024-11-26 10:17 ` [PATCH v2 5/6] x86/fpu/xstate: Create guest fpstate with guest specific config Chao Gao
2025-03-04 23:02   ` Dave Hansen
2025-03-05  9:04     ` Chao Gao
2024-11-26 10:17 ` [PATCH v2 6/6] x86/fpu/xstate: Warn if CET supervisor state is detected in normal fpstate Chao Gao
2024-11-26 10:28 ` [PATCH v2 0/6] Introduce CET supervisor state support Chao Gao
2025-01-11  1:26   ` Sean Christopherson
2025-02-11  2:09     ` Xin Li
2025-03-04 19:40     ` Xin Li
2025-03-04 19:53       ` Sean Christopherson
2025-02-19  1:44 ` Chao Gao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z8gKeVN83omngleo@intel.com \
    --to=chao.gao@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=john.allen@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=weijiang.yang@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).