public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: linux-kernel@vger.kernel.org
Cc: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com,
	aruna.ramakrishna@oracle.com, TonyWWang-oc@zhaoxin.com,
	chang.seok.bae@intel.com
Subject: [PATCH 0/2] x86/pkeys: Remove unnecessary XGETBV1 dependency in signal frame exposition
Date: Thu, 13 Feb 2025 17:06:05 -0800	[thread overview]
Message-ID: <20250214010607.7067-1-chang.seok.bae@intel.com> (raw)

Hi all,

This series removes an unnecessary dependency on XGETBV1 which was
brought by commit

    ae6012d72fa6 ("x86/pkeys: Ensure updated PKRU value is XRSTOR'd").

Currently, the PKRU exposure logic overwrites xregs_state->header
->xfeatures in the signal frame, seemingly to emulate XSAVE behavior:
combining the requested feature bitmap with a processor-tracked status
bitmap derived from XGETBV(1).

A previous posting [1] attempted to handle the case where XGETBV(1) is
disabled or unexposed. However, that approach assumed this dependency was
necessary and further modified the logic to skip PKRU writes in such
cases, which appears problematic.

Instead, the XSAVE-written value can be read directly from userspace
memory, as is already done for legacy states [2]. Thus, tying PKRU
exposure in the ABI to XGETBV1 is excessive. This series refactors
reusable code into a helper and applies it to PKRU handling, fully
eliminating the XGETBV1 dependency.

Thanks,
Chang

[1]: https://lore.kernel.org/lkml/20250102075419.2559-1-TonyWWang-oc@zhaoxin.com/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/fpu/signal.c#n139

Chang S. Bae (2):
  x86/fpu: Refactor xfeature bitmask update code for sigframe XSAVE
  x86/pkeys: Simplify PKRU update in signal frame

 arch/x86/kernel/fpu/signal.c | 11 +----------
 arch/x86/kernel/fpu/xstate.h | 21 +++++++++++++++------
 2 files changed, 16 insertions(+), 16 deletions(-)


base-commit: b36de8b904b8ff2095ece7af6b3cfff8c73c2fb1
-- 
2.45.2


             reply	other threads:[~2025-02-14  1:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-14  1:06 Chang S. Bae [this message]
2025-02-14  1:06 ` [PATCH 1/2] x86/fpu: Refactor xfeature bitmask update code for sigframe XSAVE Chang S. Bae
2025-02-14  1:06 ` [PATCH 2/2] x86/pkeys: Simplify PKRU update in signal frame Chang S. Bae

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=20250214010607.7067-1-chang.seok.bae@intel.com \
    --to=chang.seok.bae@intel.com \
    --cc=TonyWWang-oc@zhaoxin.com \
    --cc=aruna.ramakrishna@oracle.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --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