Hi Ash,
Thanks a lot for the detailed explanation, I think this makes a lot more sense now! Starting with "all asynchronous exceptions go to EL1 by default" makes it easier to understand the logic behind these choices (the manual should really mention that somewhere early on before going into all the edge case details). I think I mostly got confused because I grouped SErrors with external aborts in my head (and those work differently), but after some thought I can see why things may need to work differently for asynchronous exceptions. (I thought there was also such a thing as an "asynchronous external abort" in the architecture, but I can't find it anymore? I guess I must have gotten things mixed up with old armv7 terminology there.)
I still don't quite understand the way PSTATE.A is treated in EL2. Like you said, when SCR_EL3.TMEA == HCR_EL2.AMO == PSTATE.A == 1, the exception is taken to EL3 (whereas with PSTATE.A == 0 it is taken to EL2). But when SCR_EL3.TMEA == 0 in the same situation, it looks like the exception is taken to EL2 regardless of the state of PSTATE.A? Why would setting SCR_EL3.TMEA affect whether PSTATE.A "works" in EL2?
Anyway, it seems like there's no better solution to my scenario than setting either AMO or TGE whenever I'm executing in EL2 and clearing it again when transitioning back. But I guess that works.
Thanks, Julius
On Wed, Nov 19, 2025 at 6:52 AM Ash Wilding Ash.Wilding@arm.com wrote:
Hi Julius,
In the Arm Architecture, all asynchronous exceptions (IRQ, FIQ, SError) target EL1 by default, unless specifically overridden to be routed EL2 by HCR_EL2.{IMO, FMO, AMO} or overridden to be routed to EL3 by SCR_EL3.{IRQ, FIQ, EA}; if both EL2 and EL3 try to route a particular type of asynchronous exception to their respective EL – for example HCR_EL2.AMO == SCR_EL3.EA == 1, then EL3 “wins” as it’s more privileged and the exception will be routed to EL3.
Separately, the PSTATE.{A, I, F} fields control whether the corresponding type of asynchronous exception is taken in the current EL, but does not prevent an exception from being routed to a higher EL.
So for example, you may have SCR_EL3.FIQ == 1, meaning FIQs are routed to EL3. If you’re currently executing at EL1 and an FIQ is asserted to the core, then the value of PSTATE.F is ignored and the exception is taken to EL3. This is by design, otherwise less privileged software could for example DoS the more privileged software if that FIQ corresponded to a timer tick / maintenance interrupt.
Another nuance here is that an asynchronous exception being asserted which targets a lower exception level than we’re currently executing in will be pended until we return back to either that level (or an even lower level).
For example, if we have HCR_EL2.EA == SCR_EL3.EA == 0, meaning SErrors are targeting the default EL1, and an SError is asserted to the core while executing in EL3, then we will not take the SError exception and it will instead become pending until we return back to EL1/EL0, at which point we’ll take the SError exception – if not masked by PSTATE.A.
The final bit of nuance here is around the NMEA and TMEA bits.
The NMEA bit basically says “If we’re executing at the current EL and an SError is asserted that would have been masked by PSTATE.A, take the SError anyway” – with some rules around when this is possible so as to prevent us from e.g. taking an SError in the middle of stacking off context at the entrypoint of some other exception handler.
And the TMEA bit basically says “Route an SError / Synchronous External Abort to me, but only if it’s not been handled by a lower EL”. As an example, if we have something like SCR_EL3.TMEA == HCR_EL2.AMO == PSTATE.A == 1, then we could imagine two scenarios:
We’re executing in EL1 and an SError is asserted PSTATE.A is ignored the SError is routed to EL2.
We’re executing in EL2 and an SError is asserted PSTATE.A masks the SError the SError is trapped to EL3 since it wasn’t handled by a lower EL (or more accurately, it was masked by all lower ELs).
Hope that helps to clarify :-)
Cheers,
Ash.