The general recommendation is to keep SError masked only for very short durations, otherwise there is a risk of missing or delaying detection of asynchronous system errors.

During nested SError handling (e.g., in serror_sp_elx), the assumption is that all lower EL exceptions are already synchronized and triggered, and any further SErrors at this point would either:

The typical path for lower EL SError handling includes: handle_lower_el_async_ea() → delegate_async_ea() → ea_proceed(), This can potentially involve platform-specific EL transitions via plat_ea_handler().

TF-A does not generally support full nested exception handling, but it provides specific handling for synchronized SErrors at exception boundaries, This is why you see dedicated logic for nested SError handling in that case.

Double fault scenario from TF-A PoV Double fault scenario would arise when platform is handling a fault in lower EL using plat_ea_handler() and another fault happens which would trap into EL3. TF-A provides a hook to handle double faults. BTW double-fault is technically not a nested exception handling but I must say it is not fully tested path (as no platform has implemented this weak definition)

Regarding https://github.com/ARM-software/arm-trusted-firmware/commit/c72200357aed49fd51dc21e45d4396f5402df811

As you mentioned it is just for cleaning up confusion around esr_el3 storage. In a SW where you never expect nested exception you should not save the value of ESR_EL3 (which is case for TF-A generally). There are two special cases where we need storage for it to preserve the original value as mentioned in commit message.

Finally, It sounds like your concern is with multiple pending SErrors from lower ELs, rather than new faults generated by EL3 itself. This can happen if you're encountering a burst of SErrors triggered in quick succession, and they are not being fully drained before control returns. Ideally, such errors should be handled collectively, but if that doesn’t happen, you may observe sequential SError exceptions, giving the appearance of repeated or nested faults.

In such scenarios, FEAT_IESB is expected to synchronize and drain all asynchronous exceptions at the exception boundary (TF-A assumes that if FEAT_RAS is there FEAT_IESB is also there). However, if IESB is not sufficient on your platform, you could try adding a DSB before the unmask_async_ea() call in handle_pending_async_ea(), assuming your execution path flows through this point. This ensures that all outstanding asynchronous faults are fully synchronized and that further SErrors are not prematurely delivered, helping to mitigate repeated exception entries caused by undrained fault conditions.

From: Jaiprakash Singh via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 19 June 2025 09:30
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: [TF-A] TF-A - sError Queries

For example, while handing nested sError, we can keep sError masked in serror_sp_elx. So that no further sError comes to EL3.

And unmask sError when returning to lower ELs. Do you think this will create any problem in the system?

Do you think we should have similar nested sError handling in serror_sp_el0? If not, what is the reason?

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.