Hi Jaiprakash,

[Answer 1]

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:

* Be caused by EL3 execution itself (which is rare), or

* Be due to pending asynchronous SErrors originating from lower ELs, which may reappear during delegated handling.

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().

[Answer 2] 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.

[Answer 3] 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/c72200357aed49fd... 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.

Thanks Manish ________________________________ 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

Hi,

I have below queries regarding nested sError handling in TF-A, please help.

1. While handling exceptions in EL3, sError is almost unmask most of the time. Any specific reason to keep sError unmasked?

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?

1. In system, sError can happen at any time. At EL3, we have nested sError handling in serror_sp_elx.

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

1. Double fault will always lead to unhandled exception. * Can someone help define double fault scenario? * What is the purpose of this patch - https://github.com/ARM-software/arm-trusted-firmware/commit/c72200357aed49fd...https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ARM-2Dsoftware_arm-2Dtrusted-2Dfirmware_commit_c72200357aed49fd51dc21e45d4396f5402df811&d=DwMFAw&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=ojpEnsKEhT3RxCsLXjvuIzv8s1dMgZJhK0amCYp00wU3WfmUmosyllzvZyH41SOm&s=V_SFQf2N9YJ8qd7DqATqOb46NDSui39FiHYhWx14kjU&e=

Is purpose only to save esr_el3 register?

Thanks

Regards,

Jaiprakash

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.