Lines Matching refs:interrupts
4 This framework is responsible for managing interrupts routed to EL3. It also
8 #. It should be possible to route interrupts meant to be handled by secure
9 software (Secure interrupts) to EL3, when execution is in non-secure state
13 that secure interrupts are under the control of the secure software with
17 #. It should be possible to route interrupts meant to be handled by
18 non-secure software (Non-secure interrupts) to the last executed exception
64 to the First Exception Level (FEL) capable of handling interrupts. When
84 which ones are valid or invalid. EL3 interrupts are currently supported only
95 Secure-EL1 interrupts
100 control of handling secure interrupts.
115 Non-secure interrupts
120 interrupts, perform its book-keeping and hand the interrupt to the
123 interrupts.
141 .. _EL3 interrupts: argument
143 EL3 interrupts
152 invalid as EL3 interrupts are unconditionally routed to EL3, and EL3
153 interrupts will always preempt Secure EL1/EL0 execution. See :ref:`exception
181 Arm GICv2 interrupt controller, Secure-EL1 interrupts are signaled through the
182 FIQ signal while Non-secure interrupts are signaled through the IRQ signal.
207 #. Although the framework has support for 2 types of secure interrupts (EL3
209 like Arm GICv3 has architectural support for EL3 interrupts in the form of
210 Group 0 interrupts. In Arm GICv2, all secure interrupts are assumed to be
217 #. Interrupt management: the following sections describe how interrupts are
253 controller to distinguish between secure and non-secure interrupts. The platform
256 enable the secure interrupts, ensure that their priority is always higher than
257 the non-secure interrupts and target them to the primary CPU. It should also
259 handling of interrupts.
263 interrupts and the IRQ signal is used to generate non-secure interrupts in either
264 security state. EL3 interrupts are not considered.
351 interrupts. This API also requires the caller to specify the routing model for
403 for ferrying interrupts between secure and non-secure software depending upon
425 The TSPD only handles Secure-EL1 interrupts and is provided with the following
428 - Secure-EL1 interrupts are routed to EL3 when execution is in non-secure
430 i.e **CSS=0, TEL3=0** & **CSS=1, TEL3=1** for Secure-EL1 interrupts
433 model is used for non-secure interrupts. They are routed to the FEL in
435 Non-secure interrupts.
438 non secure interrupts are routed to EL3 when execution is in secure state
439 i.e **CSS=0, TEL3=1** for non-secure interrupts. This effectively preempts
440 Secure-EL1. The default routing model is used for non secure interrupts in
449 interrupts in the ``sel1_intr_entry`` field. The TSPD passes control to the TSP at
453 masks all interrupts (``PSTATE.DAIF`` bits) when it calls
458 #. The TSPD implements a handler function for Secure-EL1 interrupts. This
475 implements a handler function for non-secure interrupts. This function is
500 #. In the code where IRQ, FIQ or both interrupts are enabled, if an interrupt
503 handling interrupts. This mode applies to both Secure-EL1 and non-secure
504 interrupts.
506 #. In the code where both interrupts are disabled, if an interrupt type is
508 non-secure state. Any non-secure interrupts will be handled as described
509 in the routing model where **CSS=1 and TEL3=0**. Secure-EL1 interrupts
512 as the **synchronous mode** of handling interrupts.
524 the FIQ signal is used to generate Secure-EL1 interrupts and the IRQ signal
525 is used to generate non-secure interrupts in either security state.
527 Secure payload IHF design w.r.t secure-EL1 interrupts
530 #. **CSS=0, TEL3=0**. If ``PSTATE.F=0``, Secure-EL1 interrupts will be
532 IHF should implement support for handling FIQ interrupts asynchronously.
534 If ``PSTATE.F=1`` then Secure-EL1 interrupts will be handled as per the
536 by exporting a separate entrypoint for Secure-EL1 interrupts to the SPD
547 #. **CSS=0, TEL3=1**. Secure-EL1 interrupts are routed to EL3 when execution
550 call the handler registered by the SPD service for Secure-EL1 interrupts.
554 Secure payload IHF design w.r.t non-secure interrupts
557 #. **CSS=0, TEL3=0**. If ``PSTATE.I=0``, non-secure interrupts will be
570 #. **CSS=0, TEL3=1**. Non-secure interrupts are routed to EL3. They will not
577 #. **CSS=1, TEL3=0**. Non-secure interrupts are handled in the FEL in
581 A Secure Payload must also ensure that all Secure-EL1 interrupts are correctly
583 firmware. It should configure any additional Secure-EL1 interrupts which the EL3
589 The routing model for Secure-EL1 and non-secure interrupts chosen by the TSP is
596 interrupts taken in non-secure state and routed through the TSPD service
645 #. Determining the type of interrupt. Secure-EL1 interrupts will be signaled
646 at the FIQ vector. Non-secure interrupts will be signaled at the IRQ
702 interrupts. A non-secure interrupt should never be routed to EL3 from
704 interrupts are routed to S-EL1 when execution is in Secure state, then a
739 The routing model allows non-secure interrupts to interrupt Secure-EL1 when in
741 should implement a mechanism for routing these interrupts to the last known
758 The example TSPD service registers a handler for Secure-EL1 interrupts taken
760 Secure-EL1 interrupts are handled in S-EL1 by TSP. Its handler
826 non-secure interrupts can cause preemption of TSP since there are no EL3
827 interrupts in the system. With ``EL3_EXCEPTION_HANDLING=1`` however, any EL3
843 routing of non-secure interrupts from secure state to EL3. This is to prevent
845 handling Secure-EL1 interrupts that triggered while execution was in the normal
923 non-secure and Secure-EL1 interrupts at the IRQ and FIQ vectors in its exception
956 The TSP handles interrupts under the asynchronous model as follows.
958 #. Secure-EL1 interrupts are handled by calling the ``tsp_common_int_handler()``
961 #. Non-secure interrupts are handled by calling the ``tsp_common_int_handler()``