Hi Julius,

Happy to help :-)

Asynchronous External Aborts were renamed to SErrors (and expanded in scope/definition) in Armv8. You can still see holdovers of this in certain places, such as with the SError routing bit in SCR[_EL3] still being named “EA”.

I think some of the confusion here may be stemming from the fact that is Table D1-14 is not actually telling you whether the exception is taken/masked, rather, it’s strictly telling you which EL is the target EL of the exception.

That’s a subtle but important difference, and in fact whether an exception is taken/masked is described separately in Table D1-22.

In the example you give, the row in table D1-14 with SCR_EL3.TMEA == 0 and HCR_EL2.AMO == 1 shows that regardless of the value of PSTATE.A, the target exception level is EL2 if we’re currently executing in EL0/EL1/EL2 whereas the exception is pended if we’re currently executing in EL3.

Finding the corresponding rows in Table D1-22 you can see that SCTLR2_EL2.NMEA being toggled on upgrades the masking rules when currently executing at EL2 from “B” (the SError may be subject to masking by PSTATE.A) to “A” (the SError is taken regardless of the value of PSTATE.A”).

The key here is that you need to combine Tables D1-14 and D1-22 together.

For example, you’ll notice that in Table D1-22, toggling SCR_EL3.TMEA on also upgrades the masking rules when currently executing at any of EL0/EL1/EL2 to “A”, meaning the exception is always taken. This may sound odd at first, but it’s correct as it’s saying that we’ll either be taking the exception at a lower EL, or we’ll be trapping the exception up to EL3 if it was masked by all lower levels; so the exception will definitely be taken *somewhere*, and Table D1-14 tells you where that will be depending on the values of SCR_EL3.EA / HCR_EL2.AMO / HCRX_EL2.TMEA / etc.

Cheers,

Ash.