Agree with Olivier. We should line up to FF-A spec recommendation.

Varun, if there are other issues caused by this happy to sync internally. +@Nicolas Benech for vis (Nico, FYI – this is on public mailing list)

-Raghu

From: Olivier Deprez <Olivier.Deprez@arm.com>
Sent: Tuesday, June 6, 2023 7:53 AM
To: TF-A Mailing List <tf-a@lists.trustedfirmware.org>; Varun Wadekar <vwadekar@nvidia.com>
Cc: Raghupathy Krishnamurthy <raghupathyk@nvidia.com>
Subject: Re: EHF and SPMD G0 interrupt handling issues

External email: Use caution opening links or attachments

Hi Varun,

for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today.

Can you please have a look at https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16047 ?

and https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16047/6/docs/getting_started/build-options.rst#464

The model, by the FF-A specification, is to permit G0 interrupts to trap to EL3 when NWd runs.

A G0 interrupt is routed to a SP through the SPMD/SPMC by the use of EL3-SP direct messages:

https://review.trustedfirmware.org/q/topic:%22el3_direct_msg%22+(status:open%20OR%20status:merged)

When SEL1/0 runs, G0 interrupts are first trapped to SEL2 and forwarded to EL3 by the FFA_EL3_INTR_HANDLE ABI.

I appreciate the legacy capability to let G0 interrupts trap to EL3 while SWd runs is not possible/recommended with this design.

This might indeed break earlier implementations; would it make sense aligning SW stacks to the latest of the FF-A spec recommendations?

I let Raghu chime in if need be.

Regards,

Olivier.

From: Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 06 June 2023 13:12
To: TF-A Mailing List <tf-a@lists.trustedfirmware.org>
Subject: [TF-A] EHF and SPMD G0 interrupt handling issues

Hi,

We are in the process of upgrading the downstream TF-A to v2.9 for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today.

I noticed that v2.9 has added G0 interrupt handling support to the SPMD. But I think the SPMD support still needs some work as it does not play nicely with EHF.

I have found the following issues with the implementation.

SPMD and EHF both register handlers for G0 interrupts. But the interrupt management framework only allows one handler for INTR_TYPE_EL3.
The RAS framework still uses EHF and the SPMD interrupt handler breaks that functionality.
The SPMD handler calls into the platform which does not have any means to invoke the RAS interrupt handler.

IMO, we should make SPMD a client of the EHF instead of creating yet another way for interrupt handling. For now, I register SPMD's G0 interrupt handler only if EL3_EXCEPTION_HANDLING=0, as a workaround.

Thoughts?