Re: [PATCH v2 2/6] armv8: Always unmask SErrors

From: Tom Rini <trini@konsulko.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Simon Glass <sjg@chromium.org>,
	Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Michael Walle <michael@walle.cc>, Nishanth Menon <nm@ti.com>,
	Alison Wang <alison.wang@nxp.com>,
	Peter Hoyes <Peter.Hoyes@arm.com>,
	Marek Vasut <marek.vasut+renesas@gmail.com>,
	Priyanka Jain <priyanka.jain@nxp.com>,
	Priyanka Singh <priyanka.singh@nxp.com>,
	Mark Kettenis <mark.kettenis@xs4all.nl>,
	u-boot@lists.denx.de
Subject: Re: [PATCH v2 2/6] armv8: Always unmask SErrors
Date: Wed, 2 Mar 2022 17:41:13 -0500	[thread overview]
Message-ID: <20220302224113.GV5020@bill-the-cat> (raw)
In-Reply-To: <20220211112939.1327953-3-andre.przywara@arm.com>

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

On Fri, Feb 11, 2022 at 11:29:35AM +0000, Andre Przywara wrote:

> The ARMv8 architecture describes the "SError interrupt" as the fourth
> kind of exception, next to synchronous exceptions, IRQs, and FIQs.
> Those SErrors signal exceptional conditions from which the system might
> not easily recover, and are normally generated by the interconnect as a
> response to some bus error. A typical situation is access to a
> non-existing memory address or device, but it might be deliberately
> triggered by a device as well.
> The SError interrupt replaces the Armv7 asynchronous abort.
> 
> Trusted Firmware enters U-Boot (BL33) typically with SErrors masked,
> and we never enable them. However any SError condition still triggers
> the SError interrupt, and this condition stays pending, it just won't be
> handled. If now later on the Linux kernel unmasks the "A" bit in PState,
> it will immediately take the exception, leading to a kernel crash.
> This leaves many people scratching their head about the reason for
> this, and leads to long debug sessions, possibly looking at the wrong
> places (the kernel, but not U-Boot).
> 
> To avoid the situation, just unmask SErrors early in the ARMv8 boot
> process, so that the U-Boot exception handlers reports them in a timely
> manner. As SErrors are typically asynchronous, the register dump does
> not need to point at the actual culprit, but it should happen very
> shortly after the condition.
> 
> For those exceptions to be taken, we also need to route them to EL2,
> if U-Boot is running in this exception level.
> 
> This removes the respective code snippet from the Freescale lowlevel
> routine, as this is now handled in generic ARMv8 code.
> 
> Reported-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Applied to u-boot/next, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]