Hi Julius,

I’ve been discussing this internally and realise my description of NMEA / TMEA earlier was a bit off. Apologies, I’d wrongly conflated some of the separate behaviour around the way FEAT_NMI added support for non-maskable IRQs/FIQs and using PSTATE.SP as a mask.

In my first reply to you I said:

<quote>

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”.

</quote>

In practice, an SError taken when NMEA=1 *can* corrupt state if you happened to be in the middle of stacking off registers / etc. in an exception handler at the time of taking the SError.

With that in mind, setting NMEA=1 at ELx effectively says “I'd rather corrupt volatile state in SPSR_ELx / ELR_ELx / ESR_ELx / etc. than propagate an error by not taking an exception right now”, and then TMEA being set at a higher EL effectively says “Route the SError to me if it’s masked at the target EL, or would corrupt volatile state.”

We can see this in rows 2 and 4 of Table D1-14.

Row 2 says:

- HCRX_EL2.TMEA == PSTATE.A == 1

- SCTLR2_EL1.NMEA == 0

- SErrors at EL0 go to EL2 because they’re masked by PSTATE.A

- SErrors at EL1 also go to EL2 because they’re masked by PSTATE.A

Row 4 says:

- HCRX_EL2.TMEA == PSTATE.A == 1

- SCTLR2_EL1.NMEA == 1

- SErrors at EL0 go to EL1 because NMEA overrides PSTATE.A

- SErrors at EL1 instead go to EL2 because NMEA overriding PSTATE.A may lead to corrupt state at EL1, and this is trapped by TMEA

As an aside, a positive outcome of this internal discussion is that we’ve captured a JIRA to improve the descriptions of the NMEA and TMEA bits in a future release of the Arm ARM, which should make the above behaviour more readily understandable :-)

Cheers,

Ash.