From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Peter Collingbourne <pcc@google.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] arm64/sme: Move storage of reg_smidr to __cpuinfo_store_cpu()
Date: Mon, 16 Dec 2024 14:44:07 +0000 [thread overview]
Message-ID: <864j33sn60.wl-maz@kernel.org> (raw)
In-Reply-To: <Z2A502_EpqvLYN8g@J2N7QTR9R3.cambridge.arm.com>
On Mon, 16 Dec 2024 14:31:47 +0000,
Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Mon, Dec 16, 2024 at 01:23:55PM +0000, Mark Brown wrote:
> > On Mon, Dec 16, 2024 at 12:44:14PM +0000, Mark Rutland wrote:
> >
> > > ... didn't matter either way, and using '&boot_cpu_data' was intended to
> > > make it clear that the features were based on the boot CPU's info, even
> > > if you just grepped for that and didn't see the surrounding context.
> >
> > Right, that was my best guess as to what was supposed to be going on
> > but it wasn't super clear. The code could use some more comments.
> >
> > > I think the real fix here is to move the reading back into
> > > __cpuinfo_store_cpu(), but to have an explicit check that SME has been
> > > disabled on the commandline, with a comment explaining that this is a
> > > bodge for broken FW which traps the SME ID regs.
> >
> > That should be doable.
> >
> > There's a few other similar ID registers (eg, we already read GMID_EL1
> > and MPAMIDR_EL1) make me a bit nervous that we might need to generalise
> > it a bit, but we can deal with that if it comes up. Even for SME the
> > disable was added speculatively, the factors that made this come up for
> > SVE are less likely to be an issue with SME.
>
> FWIW, I had a quick go (with only the SME case), and I think the shape
> that we want is roughly as below, which I think is easy to generalise to
> those other cases.
>
> MarcZ, thoughts?
>
> Mark.
>
> ---->8----
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 8b4e5a3cd24c8..f16eb99c10723 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -91,6 +91,16 @@ struct arm64_ftr_override {
> u64 mask;
> };
>
> +static inline u64
> +arm64_ftr_override_apply(const struct arm64_ftr_override *override,
> + u64 val)
> +{
> + val &= ~override->mask;
> + val |= override->val & override->mask;
> +
> + return val;
> +}
> +
> /*
> * @arm64_ftr_reg - Feature register
> * @strict_mask Bits which should match across all CPUs for sanity.
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 6ce71f444ed84..faad7d3e4cf5f 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1167,12 +1167,6 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
> id_aa64pfr1_sme(read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1))) {
> unsigned long cpacr = cpacr_save_enable_kernel_sme();
>
> - /*
> - * We mask out SMPS since even if the hardware
> - * supports priorities the kernel does not at present
> - * and we block access to them.
> - */
> - info->reg_smidr = read_cpuid(SMIDR_EL1) & ~SMIDR_EL1_SMPS;
> vec_init_vq_map(ARM64_VEC_SME);
>
> cpacr_restore(cpacr);
> @@ -1550,10 +1544,8 @@ u64 __read_sysreg_by_encoding(u32 sys_id)
> }
>
> regp = get_arm64_ftr_reg(sys_id);
> - if (regp) {
> - val &= ~regp->override->mask;
> - val |= (regp->override->val & regp->override->mask);
> - }
> + if (regp)
> + val = arm64_ftr_override_apply(regp->override, val);
>
> return val;
> }
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index d79e88fccdfce..1460e3541132f 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -439,6 +439,24 @@ static void __cpuinfo_store_cpu_32bit(struct cpuinfo_32bit *info)
> info->reg_mvfr2 = read_cpuid(MVFR2_EL1);
> }
>
> +static void __cpuinfo_store_cpu_sme(struct cpuinfo_arm64 *info)
> +{
> + /*
> + * TODO: explain that this bodge is to avoid trapping.
> + */
> + u64 pfr1 = info->reg_id_aa64pfr1;
> + pfr1 = arm64_ftr_override_apply(&id_aa64pfr1_override, pfr1);
> + if (!id_aa64pfr1_sme(pfr1))
> + return;
I don't think blindly applying the override at this stage is a good
thing. Specially not the whole register, and definitely not
non-disabling values.
It needs to be done on a per feature basis, and only to disable
things.
See the hack I posted for the things I think need checking.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-12-16 14:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-14 0:52 [PATCH] arm64/sme: Move storage of reg_smidr to __cpuinfo_store_cpu() Mark Brown
2024-12-14 10:56 ` Marc Zyngier
2024-12-16 12:17 ` Mark Brown
2024-12-16 12:44 ` Mark Rutland
2024-12-16 13:23 ` Mark Brown
2024-12-16 14:31 ` Mark Rutland
2024-12-16 14:44 ` Marc Zyngier [this message]
2024-12-16 15:11 ` Mark Rutland
2024-12-16 12:38 ` Mark Rutland
2024-12-16 14:31 ` Marc Zyngier
2024-12-16 15:05 ` Mark Brown
2024-12-16 15:07 ` Mark Rutland
2024-12-16 15:21 ` Mark Brown
2024-12-16 15:28 ` Marc Zyngier
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=864j33sn60.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pcc@google.com \
--cc=stable@vger.kernel.org \
--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.