Lines Matching refs:EL1
11 the interrupt to either software in EL3 or Secure-EL1 depending upon the
21 knowledge of software executing in Secure-EL1/Secure-EL0. The choice of
35 #. Secure EL1 interrupt. This type of interrupt can be routed to EL3 or
36 Secure-EL1 depending upon the security state of the current execution
37 context. It is always handled in Secure-EL1.
40 Secure-EL1, Non-secure EL1 or EL2 depending upon the security state of the
41 current execution context. It is always handled in either Non-secure EL1
44 #. EL3 interrupt. This type of interrupt can be routed to EL3 or Secure-EL1
85 for GIC version 3.0 (Arm GICv3) and only the Secure-EL1 and Non-secure interrupt
95 Secure-EL1 interrupts
104 handover the interrupt to Secure-EL1 for handling.
113 can handover the interrupt to Secure-EL1 for handling.
127 the state of software in Secure-EL1/Secure-EL0 before handing the
129 coordination between Secure-EL1 and EL3 software to ensure that the
147 Secure-EL1/Secure-EL0. This is a valid routing model as secure software
148 in Secure-EL1/Secure-EL0 is in control of how its execution is preempted
153 interrupts will always preempt Secure EL1/EL0 execution. See :ref:`exception
157 Secure-EL1/Secure-EL0. This is a valid routing model as secure software
181 Arm GICv2 interrupt controller, Secure-EL1 interrupts are signaled through the
195 For example, in Arm GICv3, when the execution context is Secure-EL1/
199 route the FIQ signal to EL3 when executing in Secure-EL1/Secure-EL0, thereby
208 and Secure-EL1 interrupt), only interrupt controller architectures
211 handled in Secure-EL1. They can be delivered to Secure-EL1 via EL3 but they
227 software stack spanning from EL3 to Secure-EL1. These components are described
262 is considered and it is assumed that the FIQ signal is used to generate Secure-EL1
270 following components of software running in EL3 and Secure-EL1. Each component is
276 Secure Payload (SP) software which runs in Secure-EL1/Secure-EL0 and is
289 to a Secure OS which runs in Secure-EL1/Secure-EL0. It interfaces with the
292 which runs only in Secure-EL1.
350 this API to register a handler for Secure-EL1 and optionally for non-secure
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
440 Secure-EL1. The default routing model is used for non secure interrupts in
448 ``tsp_vectors`` in the SP which also includes the handler for Secure-EL1
450 this address when it receives a Secure-EL1 interrupt.
458 #. The TSPD implements a handler function for Secure-EL1 interrupts. This
496 A Secure Payload must implement an interrupt handling framework at Secure-EL1
497 (Secure-EL1 IHF) to support its chosen interrupt routing model. Secure payload
501 type is targeted to the FEL, then it will be routed to the Secure-EL1
503 handling interrupts. This mode applies to both Secure-EL1 and non-secure
509 in the routing model where **CSS=1 and TEL3=0**. Secure-EL1 interrupts
518 (see `Valid routing models`_) effects the implementation of the Secure-EL1
524 the FIQ signal is used to generate Secure-EL1 interrupts and the IRQ signal
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
531 triggered at one of the Secure-EL1 FIQ exception vectors. The Secure-EL1
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
549 in Secure-EL1/Secure-EL0 will not mask FIQs. The EL3 runtime firmware will
550 call the handler registered by the SPD service for Secure-EL1 interrupts.
551 Secure-EL1 IHF should then handle all Secure-EL1 interrupt through the
558 triggered at one of the Secure-EL1 IRQ exception vectors . The Secure-EL1
571 be visible to the SP. The ``PSTATE.I`` bit in Secure-EL1/Secure-EL0 will
574 the non-secure state where the interrupt will be handled. The Secure-EL1
578 non-secure state (EL1/EL2) and are not visible to the SP. This routing
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
595 The TSP implements an entrypoint (``tsp_sel1_intr_entry()``) for handling Secure-EL1
602 exceptions taken at the same (Secure-EL1) exception level. This table is
645 #. Determining the type of interrupt. Secure-EL1 interrupts will be signaled
701 An SPD service can register a handler for Secure-EL1 and/or Non-secure
703 from non-secure state. Also if a routing model is chosen where Secure-EL1
704 interrupts are routed to S-EL1 when execution is in Secure state, then a
705 S-EL1 interrupt should never be routed to EL3 from secure state. The handler
709 routing model and interrupt type. For non secure and S-EL1 interrupt,
715 #. A Secure-EL1 interrupt taken from the non-secure state should be
728 per the synchronous interrupt handling model it implements. A Secure-EL1
731 another higher priority Secure-EL1 interrupt or a EL3 interrupt. The SPD
739 The routing model allows non-secure interrupts to interrupt Secure-EL1 when in
749 When the Secure Payload has finished handling a Secure-EL1 interrupt, it could
752 exception level and the security state from where the Secure-EL1 interrupt was
755 Test secure payload dispatcher Secure-EL1 interrupt handling
758 The example TSPD service registers a handler for Secure-EL1 interrupts taken
759 from the non-secure state. During execution in S-EL1, the TSPD expects that the
760 Secure-EL1 interrupts are handled in S-EL1 by TSP. Its handler
761 ``tspd_secure_el1_interrupt_handler()`` expects only to be invoked for Secure-EL1
777 to re-enter TSP for Secure-EL1 interrupt processing. It does not need to
793 when a Secure-EL1 interrupt is generated when execution is in the non-secure
823 The TSP in Secure-EL1 can be preempted by a non-secure interrupt during
825 Secure-EL1 interrupt processing. When ``EL3_EXCEPTION_HANDLING`` is ``0``, only
831 the TSP either for Secure-EL1 interrupt handling or for resuming the preempted
835 The non-secure interrupt triggered in Secure-EL1 during ``yielding`` SMC
836 processing can be routed to either EL3 or Secure-EL1 and is controlled by build
845 handling Secure-EL1 interrupts that triggered while execution was in the normal
853 trigger at Secure-EL1 IRQ exception vector. The TSP saves the general purpose
913 In the synchronous model, it should begin handling a Secure-EL1 interrupt after
916 should save any Secure-EL1 system register context which is needed for resuming
923 non-secure and Secure-EL1 interrupts at the IRQ and FIQ vectors in its exception
933 The TSPD hands control of a Secure-EL1 interrupt to the TSP at the
958 #. Secure-EL1 interrupts are handled by calling the ``tsp_common_int_handler()``