Hi,
On 1- per discussion with arch team (@Marc Bonnicimailto:Marc.Bonnici@arm.com please chime in) there were reasons why FFA_ABORT isn't favoured for this case as it was initially defined to be used at the secure virtual FF-A instance (aka SPMC to SP boundary). The FFA_ABORT at secure physical FF-A instance was reserved to the EL3 SPMC usage.
Afaiu FIRME might be a better place for this use case, as this is also requested on R-EL2 side and a good reason for a common standard outside of FF-A or RMM spec.
On 2- a way to think about it might be EL3 notifying normal world about a fatal error (whichever conduit being SDEI, GIC interrupt, or SEA/Serror injection if possible), and then normal world to coordinate a graceful tear down of secure world through impdef partition messages. Normal world is the entity relinquishing cpu cycles to the secure world and hence should be responsible in its crash dump scenario. This behavior might also better fit future GICv5 architecture and non-preemptive secure interrupts.
Stealing CPU cycles like a secure interrupt does through FIQ might lead to blank periods that normal world may not handle properly.
Regards, Olivier.
________________________________ From: Manish Pandey2 via Hafnium hafnium@lists.trustedfirmware.org Sent: 14 September 2026 13:17 To: Jack Suann jsuann@qti.qualcomm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; Varun Wadekar vwadekar@nvidia.com Subject: [Hafnium] Re: Improving abort handling in Hafnium
IIUC, there are two separate flows we are discussing:
1. Secure-side fatal error, local to an SP/SPMC-managed context: For this case, FF-A lifecycle / FFA_ABORT-style handling looks applicable and can be evaluated.
2. EL3-observed fatal/RAS event, for example while NS is executing: For this case, we may need an EL3-controlled, best-effort notification path to the Secure side, so that SPMC/SPs can quiesce or save state before reset.
For case 2, one clarification on SDEI: It is not deprecated today, but we are looking at reducing its usage over time, and use hardware feats (FEAT_E3DSE, FEAT_NMI) or SW emulated injection paths (SEA/SError injection).
SDEI is mainly useful as a notification mechanism when NS is executing with exceptions masked, but adding SDEI support on the Hafnium side would require non-trivial porting work, including an SDEI handler. Just wondering, why normal EL3/SPMD notification mechanism not enough in this case and why we need SDEI?
On a related topic, we are currently working on SW emulated SError injection in TF-A.
Thanks Manish ________________________________ From: Varun Wadekar via Hafnium hafnium@lists.trustedfirmware.org Sent: 11 September 2026 19:27 To: Jack Suann jsuann@qti.qualcomm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Subject: [Hafnium] Re: Improving abort handling in Hafnium
Hi Jack,
These are interesting use cases and would help other platform owners too IMO.
Like the idea of introducing platform hooks in the abort path. Overall the design philosophy of Hafnium is not to add platform code, so one approach might be to introduce SMC FID for the platform path instead.
For involving SP/SPMC in the fatal event handling path, have you evaluated the SP lifecycle messages? The FFA ALP5 spec chapter 18.9 has these new states that could be used for this use case, AFAICT.
Hope this helps.
-Varun
From: Jack Suann via Hafnium hafnium@lists.trustedfirmware.org Date: Wednesday, 2 September 2026 at 02:04 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Subject: [Hafnium] Improving abort handling in Hafnium
External email: Use caution opening links or attachments
Hi everyone,
As you may be aware, at Qualcomm we've been looking into various enhancements we'd like to make to Hafnium; one recent area we've identified for improvement is the fatal error handling which currently just spins on panic / abort.
To start with, we're looking at making abort() stop other CPUs and DMA, as well as introduce a platform hook to allow for platform-specific handling before propagating the error to the SPMD via FFA_ABORT; please let us know if this sound reasonable and if you have any other suggestions for improving this abort handling.
Beyond this we are also interested in improving the fatal error handling in the secure world more broadly. In particular, when a fatal event is received by TF-A then we want to give the SPMC and its SPs the opportunity to run so they can perform their own error handling before reset.
Is there a suitable framework for supporting this kind of error / reset handling? One existing mechanism for this is SDEI, though on the TF Discord it was mentioned that this has been deprecated (at least for hardware events) in favor of more recent extensions such as FEAT_NMI; would these newer extensions be suitable for software events as well? How can event handling be supported on platforms that lack these newer extensions?
Also, what would be the impact of this kind of event handling on the FF-A specification?
Thanks in advance for your support on this issue.
Regards, Jack Suann -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org