ATF GIC spurious interrupts

[olidep]

Hi,

I notice in ATF generic GIC code (drivers/arm/gic/arm_gic.c : arm_gic_get_pending_interrupt_type) that interrupt is considered S-EL1 type if id is strictly below 1022 (which may be actually strictly below 1020 as 1020-1023 are reserved or spurious interrupts).

From GICv2 with security extensions and interrupt grouping, interrupt 1022 is a spurious interrupt (in addition to 1023). So in the mentioned code an interrupt 1022 becomes typed NS interrupt which may not be correct. If there is no associated NS route, firmware panics with unhanded EL3 interrupt.

Is this expected?

Best Regards.

[danh-arm]

Are you seeing a problem in practice here? arm_gic_get_pending_interrupt_type() only returns the interrupt type, not the interrupt id. A value of 1022 means the highest priority pending interrupt is a Group 1 (i.e. Non-Secure) interrupt, which is all this interface tells you. If you want the actual NS interrupt ID, then arm_gic_get_pending_interrupt_id() is the interface you want. This latter function reads GICC_AHPPIR to get the Group 1 interrupt id in case of 1022 is read from GICC_HPPIR.

[olidep]

Hi,

Sorry for the delay and thanks for your reply.

The exact scenario I observed is that: bl31/aarch64/runtime_exceptions.S the instances or handle_interrupt_exception macro call plat_ic_get_pending_interrupt_type resolving to arm_gic_get_pending_interrupt_type

If interrupt is really a spurious interrupt 1022 then it will return NS interrupt type (not INTR_TYPE_INVAL like per interrupt 1023). Next get_interrupt_type_handler is meant to return the associated interrupt handler address. But it is likely that there is no interrupt 1022 NS handler installed within the SPD. This makes ATF panicking because of this unhandled interrupt type.

So I wonder if this special case of spurious interrupt denoting higher NS priority interrupt while running secure world should: -explicitelly declared as a specific SPD handler -or be handled internally just as 1023 spurious interrupt (as an "invalid type") in ATF ?

Kind Regards.

[danh-arm]

If you get interrupt 1022 while executing in the SP, and the SPD does not have a registered handler for NS interrupts (which seems to be the case here), then the BL31 exception vector should immediately return back to the SP, not panic. Perhaps it is the SP that is panicking by not handling the NS interrupt, not BL31?

If the SP performs any long-running tasks, then either the SP or the SPD should handle NS interrupts while executing in the SP, preferably by stopping what the SP was doing, and passing executing control back to the normal world (e.g. by sending an SMC). The TSP/TSPD has an example of this (search for TSP_PREEMPTED).

[soby-mathew]

The Non secure interrupt should have never pre-empted the SP, if the interruptrouting model was not programmed as such by the SPD. The routing model is determined by the interrupt routing bits programmed in scr_el3 and is to be done by the SPD. Hence, if the SPD has programmed the NS interrupt to pre-empt the SP and has not provided the NS handler, then its a SPD programming error.

From my reading, interrupt number 1022 on GICv2 with Interrupt Grouping and Security Extn (assuming GICC.AckCtl == 0) will only happen if there is a pending NS interrupt.