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
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
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
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
Hi everyone,
Thanks for your responses!
The main limitation with the SP lifecycle messages (and other direct messaging-based methods) is that it may not be possible to send a direct message to an SP after a fatal error occurs, e.g. when the error is delivered to the SPMC while the SP is already running, in which case the SP isn't ready to receive the framework message immediately. The SPMC or normal world scheduler would need to resume the SP and wait for it to complete its original task before sending the partition stop request, which could result in a long delay before the fatal error is handled.
Using EL3-controlled notifications may not be ideal either, as the SP may be executing with interrupts masked at the time of the error which would delay delivery of the NPI (and assumes the SP does unmask interrupts at some point); mechanisms such as SDEI, FEAT_NMI, etc. don't have this kind of delay given they cannot be masked. Note that we don't have a particular preference for SDEI over other exception delivery mechanisms, it's just the primary reference point we have for this kind of error handling.
In terms of the hardware features and other mechanisms mentioned (FEAT_E3DSE, FEAT_NMI, SDEI, SEA/SError injection), is there any preference for one of these over another? Are there specific use-cases which these are meant to be used for, or could they be used as a generic error delivery mechanism? It would be good to narrow down to one or two options rather than having to support all of them.
As for propagating an abort from the SPMC to the SPMD, we're happy to use a FIRME interface over FFA_ABORT; this suggestion was just based on Hafnium's current behavior when an SP calls FFA_ABORT with the Propagate abort action (in ffa_cpu_cycles_abort). Possibly this handler should just call the generic abort function instead, which in turn would call the FIRME interface?
Regards, Jack
From: Olivier Deprez Olivier.Deprez@arm.com Sent: Monday, September 14, 2026 9:40 PM To: Jack Suann jsuann@qti.qualcomm.com; hafnium@lists.trustedfirmware.org; Varun Wadekar vwadekar@nvidia.com; Manish Pandey2 Manish.Pandey2@arm.com; Martin Platts Martin.Platts@arm.com; Marc Bonnici Marc.Bonnici@arm.com Subject: Re: Improving abort handling in Hafnium
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. 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.orgmailto:hafnium@lists.trustedfirmware.org> Sent: 14 September 2026 13:17 To: Jack Suann <jsuann@qti.qualcomm.commailto:jsuann@qti.qualcomm.com>; hafnium@lists.trustedfirmware.orgmailto:hafnium@lists.trustedfirmware.org <hafnium@lists.trustedfirmware.orgmailto:hafnium@lists.trustedfirmware.org>; Varun Wadekar <vwadekar@nvidia.commailto: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.orgmailto:hafnium@lists.trustedfirmware.org> Sent: 11 September 2026 19:27 To: Jack Suann <jsuann@qti.qualcomm.commailto:jsuann@qti.qualcomm.com>; hafnium@lists.trustedfirmware.orgmailto:hafnium@lists.trustedfirmware.org <hafnium@lists.trustedfirmware.orgmailto: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.orgmailto:hafnium@lists.trustedfirmware.org> Date: Wednesday, 2 September 2026 at 02:04 To: hafnium@lists.trustedfirmware.orgmailto:hafnium@lists.trustedfirmware.org <hafnium@lists.trustedfirmware.orgmailto: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.orgmailto:hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.orgmailto:hafnium-leave@lists.trustedfirmware.org -- Hafnium mailing list -- hafnium@lists.trustedfirmware.orgmailto:hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.orgmailto:hafnium-leave@lists.trustedfirmware.org -- Hafnium mailing list -- hafnium@lists.trustedfirmware.orgmailto:hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.orgmailto:hafnium-leave@lists.trustedfirmware.org
hafnium@lists.trustedfirmware.org
-
Jack Suann -
Manish Pandey2 -
Olivier Deprez -
Varun Wadekar