Re: [PATCH v2] arm64: errata: Add NXP iMX8QM workaround for A53 Cache coherency issue

From: Will Deacon <will@kernel.org>
To: "Ivan T. Ivanov" <iivanov@suse.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Brown <broonie@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
	Dong Aisheng <aisheng.dong@nxp.com>, Frank Li <frank.li@nxp.com>,
	Jason Liu <jason.hui.liu@nxp.com>,
	linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com
Subject: Re: [PATCH v2] arm64: errata: Add NXP iMX8QM workaround for A53 Cache coherency issue
Date: Mon, 26 Jun 2023 13:15:29 +0100	[thread overview]
Message-ID: <20230626121528.GA19941@willie-the-truck> (raw)
In-Reply-To: <y5lcrztej6th7z3eoihiiazwwlidyhi3t2tkdjrmgcghqwt6bs@dzxxpmwfynj6>

On Mon, Jun 12, 2023 at 01:22:37PM +0300, Ivan T. Ivanov wrote:
> On 06-12 10:33, Mark Rutland wrote:
> > I'm saying that the *faulting logic* is local, not the broadcast.
> > 
> > IIUC the erratum is due to the wiring between clusters losing some bits. The
> > *recipient* of a broadcast DVM message (which is what TLBI or IC instructions
> > will generate) will receive a bogus address (and other context) to use for the
> > invalidate.
> > 
> > The CPU which executes the `IC IVAU <Xt>` instruction will check the address in
> > `<Xt>` using its local MMU to determine whether the access should fault
> > *before* sending the broadcast DVM message, and the recipients will not perform
> > any MMU check (since e.g. they could be running a different process with a
> > different VA space anyway).
> > 
> > The MMU check is local to the CPU, and doesn't depend on any broadcast; that
> > should be unaffected by the erratum. If that is affected then the erratum
> > description is wrong and we have a bigger set of problems.
> > 
> 
> Thanks, I think I get it. Now, what will be preferred way to fix IC
> TLBI instructions for this errata? Using static_key for TLBI and
> alternatives for IC instruction or something else?

As I mentioned in a previous comment, I think this should use a static_key
to drive the high-level behaviour instead of patching the low-level code
with alternatives.

> Keep trapping userspace IC instruction seems ok to me. Perhaps
> alternative for IC in invalidate_icache_by_line macro? About
> TLBI, it will be really invasive if static_key is used, I think.
> Yes, there is over invalidation, but still overall performance of
> SoC is almost doubled because of enabled 2 CA72 :-)
> 
> Another point is, should I keep hunk in arm-smmu.c, because
> cpus_have_final_cap() is not generally available for drivers?

What do you mean here? We obviously can't break the build, but I think
the easiest thing to do is add a clause to `arm_smmu_sva_supported()`
to return false if this erratum is present.

Will

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