From: Catalin Marinas <catalin.marinas@arm.com>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Mark Brown <broonie@kernel.org>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH v3] arm64: Don't read GMID_EL1 when MTE is disabled
Date: Mon, 24 Aug 2026 21:29:02 +0100 [thread overview]
Message-ID: <aoypji6EJ8zToWvh@arm.com> (raw)
In-Reply-To: <20260824184155.2644646-1-fuad.tabba@linux.dev>
On Mon, Aug 24, 2026 at 07:41:55PM +0100, Fuad Tabba wrote:
> +/*
> + * Reading GMID_EL1 when the kernel has disabled MTE traps to EL2, and the raw
> + * ID_AA64PFR1_EL1 reflects neither CONFIG_ARM64_MTE nor the cmdline override.
> + */
> +static inline bool gmid_el1_accessible(u64 pfr1)
> +{
> + if (!IS_ENABLED(CONFIG_ARM64_MTE))
> + return false;
> +
> + pfr1 &= ~id_aa64pfr1_override.mask;
> + pfr1 |= id_aa64pfr1_override.val;
> +
> + return id_aa64pfr1_mte(pfr1);
> +}
Can this function not use __read_sysreg_by_encoding() directly and not
get an argument at all? We'd get the override from that function rather
than open-coding it here. Eventually, once we get Suzuki's clamping fix,
it also ensures we won't be able to bump the MTE version to unsafe
values (but that's a different fix from this one).
If you are worried about additional trapping of the MRS, we should go
for Will's improvement to always read the cached values in
__read_sysreg_by_encoding().
--
Catalin
next prev parent reply other threads:[~2026-08-24 20:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 18:41 [PATCH v3] arm64: Don't read GMID_EL1 when MTE is disabled Fuad Tabba
2026-08-24 18:56 ` sashiko-bot
2026-08-24 19:54 ` Fuad Tabba
2026-08-24 20:29 ` Catalin Marinas [this message]
2026-08-24 22:29 ` Fuad Tabba
2026-08-25 14:14 ` Will Deacon
2026-08-25 14:46 ` Fuad Tabba
2026-08-26 11:06 ` Catalin Marinas
2026-08-27 10:23 ` Will Deacon
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=aoypji6EJ8zToWvh@arm.com \
--to=catalin.marinas@arm.com \
--cc=broonie@kernel.org \
--cc=fuad.tabba@linux.dev \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.