How do I handle Non-secure Group 1 interrupts when a core runs at Secure EL1?

原文：

Information in this article applies to:

N/A

In a GICv3 system with two Security states, an interrupt can be configured as one of the following groups:

The following table shows you that each group of interrupts uses a different interrupt signal when the core runs at a different Exception level:

Current Exception level	Group 0	Secure Group 1	Non-secure Group 1
Secure EL1 Secure EL0	FIQ	IRQ	FIQ
Non-secure EL2 Non-secure EL1 Non-secure EL0	FIQ	FIQ	IRQ
EL3	FIQ	FIQ	FIQ

In a GICv2 system that implements the Generic Interrupt Controller (GIC) Security Extensions:

In conclusion, Non-secure Group 1 interrupts are handled as follows:

In the GICv3 system:
- Non-secure Group 1 interrupts are signaled as FIQs when the core is in Secure EL1.
- Non-secure Group1 interrupts are signaled as IRQs when the core is in Non-secure state.
In the GICv2 system:
- Non-secure Group1 interrupts are signaled as IRQs when the core is in Secure EL1.
- Non-secure Group1 interrupts are signaled as IRQs when the core is in Non-secure state.

The GICv3 and GICv2 use different signals to assert the Non-secure Group 1 interrupt when the core is in Secure EL1.

When a core runs at Secure EL1, the core handles one of the following calls from the Non-secure world:

For Fast call, the PSTATE.IRQ and FIQ bits should be set. Therefore, no interrupt can be handled during a Fast call.

The target Exception level of an interrupt is configured through the FIQ and IRQ bits in SCR_EL3.

EL3 configures SCR_EL3 FIQ or IRQ bits to a target Exception level value before the core exits from EL3.

When the core switches to Secure EL1 from EL3, EL3 can configure SCR_EL3 with the following values:

An example of using the GICv3 is given below for two scenarios:

The process to handle the Non-secure Group 1 interrupt is as follows:

The GIC signals a Non-secure Group 1 interrupt as an FIQ (IRQ in GICv2).
The Secure EL1 exception vector handles the FIQ first.

The Secure EL1 reads the interrupt ID as a special Interrupt Identifier (INTID), which indicates that the pending interrupt does not belong to the current Security state.
Secure EL1 sends an SMC to EL3, as shown in the following figure.

The Secure EL1 might perform context saving before sending the SMC to EL3, depending on the usage.
EL3 receives the SMC call from Secure EL1, prepares the Non-secure context, and configures the SCR_EL3.IRQ to 0 before switching to Non-secure world, as shown in the following figure:
When the core switches to Non-secure world, the interrupt re-asserts as an IRQ, and the Non-secure world exception vector handles the interrupt.
After the interrupt handling is complete, the Non-secure world invokes an SMC to EL3 to instruct the Secure EL1 to continue execution.

images/SCR_EL3.FIQ_0_3.png

The process to handle the Non-secure Group 1 interrupt is as follows:

The GIC signals a Non-secure Group 1 interrupt as an FIQ (IRQ in GICv2) and the FIQ is routed to EL3, as shown in the following figure.
The EL3 exception vector handles the FIQ first.

The EL3 read the interrupt ID as a special INTID, which indicates that the pending interrupt belongs to Non-secure Group 1.
The EL3 prepares the Non-secure context and configures the SCR_EL3.IRQ with 0 before switching to the Non-secure world.

In this case, Secure EL1 has no chance to save any context.
When the core switches to Non-secure world, the interrupt re-asserts as IRQ, and the Non-secure world exception vector handles the interrupt.
After the interrupt handling is complete, the Non-secure world invokes an SMC to EL3 to instruct Secure EL1 to continue, as shown in the following figure:

images/SCR_EL3.FIQ_1_2.png

End