linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>,
	Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64: mte: move register initialization to C
Date: Sat, 20 Aug 2022 10:40:51 +0100	[thread overview]
Message-ID: <YwCsIm2nCXCEEgAd@arm.com> (raw)
In-Reply-To: <20220819013526.2682765-1-pcc@google.com>

On Thu, Aug 18, 2022 at 06:35:26PM -0700, Peter Collingbourne wrote:
> If FEAT_MTE2 is disabled via the arm64.nomte command line argument on a
> CPU that claims to support FEAT_MTE2, the kernel will use Tagged Normal
> in the MAIR. If we interpret arm64.nomte to mean that the CPU does not
> in fact implement FEAT_MTE2, setting the system register like this may
> lead to UNSPECIFIED behavior.

I'm not convinced by this wording. There is no UNDEFINED behaviour since
proc.S checks the raw ID regs. Just passing arm64.nomte currently still
allows fully defined behaviour (well, unless you try to map tag storage
into the linear map but changing MAIR doesn't solve that anyway).

[...]
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 907401e4fffb..3554ff869f4b 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -2030,8 +2030,47 @@ static void bti_enable(const struct arm64_cpu_capabilities *__unused)
>  #ifdef CONFIG_ARM64_MTE
>  static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
>  {
> +	u64 rgsr;
> +
>  	sysreg_clear_set(sctlr_el1, 0, SCTLR_ELx_ATA | SCTLR_EL1_ATA0);
> +
> +	/*
> +	 * CnP must be enabled only after the MAIR_EL1 register has been set
> +	 * up. Inconsistent MAIR_EL1 between CPUs sharing the same TLB may
> +	 * lead to the wrong memory type being used for a brief window during
> +	 * CPU power-up.
> +	 *
> +	 * CnP is not a boot feature so MTE gets enabled before CnP, but let's
> +	 * make sure that is the case.
> +	 */
> +	BUG_ON(read_sysreg(ttbr0_el1) & TTBR_CNP_BIT);
> +	BUG_ON(read_sysreg(ttbr1_el1) & TTBR_CNP_BIT);

Ah, good point. SCOPE_BOOT_CPU features are initialised before the
others even for late secondary CPUs, so that should work without having
to reorder the features table.

> +
> +	/* Normal Tagged memory type at the corresponding MAIR index */
> +	sysreg_clear_set(
> +		mair_el1, MAIR_ATTRIDX(MAIR_ATTR_MASK, MT_NORMAL_TAGGED),
> +		MAIR_ATTRIDX(MAIR_ATTR_NORMAL_TAGGED, MT_NORMAL_TAGGED));

Nitpick: keep 'mair_el1' on the same line with sysreg_clear_set, I think
it looks slightly better if MAIR_ATTRIDX are both aligned.

[...]
> -	/* set the TCR_EL1 bits */
> -	mov_q	x10, TCR_MTE_FLAGS
> -	orr	tcr, tcr, x10

I'd keep the TCR setting under #ifdef MTE or rather the TCR_MTE_FLAGS
and make them 0 if !MTE. It gives us a chance to still test a kernel
configuration where TBI1 == 0.

BTW, we end up setting the TCMA1 bit even when MTE is not supported. It
shouldn't be a problem usually with RES0 bits which we know what they
do.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2022-08-20  9:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19  1:35 [PATCH] arm64: mte: move register initialization to C Peter Collingbourne
2022-08-20  9:40 ` Catalin Marinas [this message]

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=YwCsIm2nCXCEEgAd@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=andreyknvl@gmail.com \
    --cc=broonie@kernel.org \
    --cc=eugenis@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=pcc@google.com \
    --cc=vincenzo.frascino@arm.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 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).