EL3 interrupt handling in ATF

[jayannad]

Hi,

We use only BL31 from ATF, BL1 and BL2 are replaced by our custom boot loaders and S-EL1 is not supported. We wanted to handle all secure requests coming to EL3 in BL31 itself.

Is there any plan to support "IRQ and FIQ exceptions taken from the current exception level" in ? GICv3 is supported in our hardware. We wanted to enable hardware error interrupts in EL3 and handle it in EL3. The current ATF code supports asynchronous exceptions taken only from lower exception level. But, we wanted to enable PSTATE.I and PSTATE.F in BL31 and handle any hardware errors that are generated before start executing from lower exception level.

Thank you, Jayanthi

[athoelke]

There is no current plan to allow unmasking IRQ and FIQ while executing in EL3. This is a much more significant problem than merely adding code to support these exception vectors.

Enabling re-entrancy in a general way in EL3 is a challenge –

• Configuration of the CPU/GIC to ensure that only what you want to interrupt EL3 can do so. This might mean:
  • using strict priorities and the ICC_PMR_EL1 or using ICC_IGRPEN1_EL3 to disable Group1 interrupts
  • adjusting SCR_EL3 on EL3 entry to ensure the interrupts are routed to EL3
  • and reverting this configuration correctly on exit
• Reconsider the design/implementation of all other EL3 code given that it may be interrupted, which has implications for critical sections, apparent non-atomic behavior etc. Interrupt-masking or other techniques will be needed to protect some regions of code
• The handling of CPU state on exceptions to BL31 would need an overhaul as we would need somewhere to store the nested EL3 CPU state on entry to the re-entrant exception

For specific use cases the challenge is more manageable, e.g. handling of Synchronous External Aborts and System Error Interrupts has less configuration challenge (no GIC) and the scope of code that is run during handling can be limited to reduce the amount of code that needs to be re-entrant.

If GIC based Error interrupts are added, the configuration becomes harder, the scope of re-entrant code increases and the risk of abuse of this feature for other interrupts arises.

I have a question relating to your request: with the current non re-entrant design of BL31, if the specific interrupt is targeted to EL3 (e.g. SCR_EL3.FIQ=1) then it will be handled in BL31. If execution is currently in EL3 with PSTATE.F=1, the exception will be delayed until an ERET to a lower exception level - but the exception is guaranteed to be taken before any code is executed at the lower exception level. Unmasking FIQ at EL3 would just reduce the latency of the interrupt. If the EL3 code is long running (in general it should not be), then an alternative to the complex support for re-entrancy would be a periodic poll of ISR_EL1 to determine if an interrupt has been signaled to the CPU.

[jayannad]

Our EL3 code is not long running. So, it should be ok to delay the interrupt handling until an ERET is executed.