Lines Matching refs:in
9 software (Secure interrupts) to EL3, when execution is in non-secure state
11 the interrupt to either software in EL3 or Secure-EL1 depending upon the
19 level in the normal world when the execution is in secure world at
21 knowledge of software executing in Secure-EL1/Secure-EL0. The choice of
23 ensures that non-secure software is able to execute in tandem with the
33 the exception level(s) it is handled in.
37 context. It is always handled in Secure-EL1.
41 current execution context. It is always handled in either Non-secure EL1
46 always handled in EL3.
48 The following constants define the various interrupt types in the framework
62 in the Secure Configuration Register at EL3 (``SCR_EL3.FIQ`` and ``SCR_EL3.IRQ``
67 state prior to entry into a lower exception level in that security state.
73 routed to EL3. A routing model is applicable only when execution is not in EL3.
75 The default routing model for an interrupt type is to route it to the FEL in
82 incorrect as they conflict with the requirements mentioned in Section 1. The
86 types are supported for GIC version 2.0 (Arm GICv2) (see `Assumptions in
87 Interrupt Management Framework`_). The terminology used in the following
98 #. **CSS=0, TEL3=0**. Interrupt is routed to the FEL when execution is in
99 secure state. This is a valid routing model as secure software is in
102 #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in secure
103 state. This is a valid routing model as secure software in EL3 can
106 #. **CSS=1, TEL3=0**. Interrupt is routed to the FEL when execution is in
111 #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
112 non-secure state. This is a valid routing model as secure software in EL3
118 #. **CSS=0, TEL3=0**. Interrupt is routed to the FEL when execution is in
122 software is in control of how its execution is preempted by non-secure
125 #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in secure
126 state. This is a valid routing model as secure software in EL3 can save
127 the state of software in Secure-EL1/Secure-EL0 before handing the
132 #. **CSS=1, TEL3=0**. Interrupt is routed to FEL when execution is in
136 #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
146 #. **CSS=0, TEL3=0**. Interrupt is routed to the FEL when execution is in
148 in Secure-EL1/Secure-EL0 is in control of how its execution is preempted
156 #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in
158 in EL3 can handle the interrupt.
160 #. **CSS=1, TEL3=0**. Interrupt is routed to the FEL when execution is in
165 #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
166 non-secure state. This is a valid routing model as secure software in EL3
177 programmed in ``SCR_EL3`` while applying the routing model for a type of
179 ``plat_interrupt_type_to_line()`` API (described in the
183 This applies when execution is in either security state.
190 particular security state, then interrupt signal will be routed to EL3 when in
193 borne in mind when choosing the routing model for an interrupt type.
195 For example, in Arm GICv3, when the execution context is Secure-EL1/
198 that **TEL3=1** when **CSS=0**, the FIQ bit in ``SCR_EL3`` will be programmed to
199 route the FIQ signal to EL3 when executing in Secure-EL1/Secure-EL0, thereby
202 Assumptions in Interrupt Management Framework
209 like Arm GICv3 has architectural support for EL3 interrupts in the form of
211 handled in Secure-EL1. They can be delivered to Secure-EL1 via EL3 but they
212 cannot be handled in EL3.
215 in EL3.
226 Both aspects of interrupt management involve various components in the secure
228 in the section `Software components`_. The framework stores information
229 associated with each type of interrupt in the following data structure.
239 The ``flags`` field stores the routing model for the interrupt type in
240 bits[1:0]. Bit[0] stores the routing model when execution is in the secure
241 state. Bit[1] stores the routing model when execution is in the non-secure
242 state. As mentioned in Section `Routing model`_, a value of ``0`` implies that
245 macro ``set_interrupt_rm_flag()`` should be used to set the bits in the
249 model in the ``flags`` field to the corresponding bit in the ``SCR_EL3`` for each
254 is expected to be aware of the secure devices present in the system and their
258 export the interface described in the :ref:`Porting Guide` to enable
263 interrupts and the IRQ signal is used to generate non-secure interrupts in either
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
281 interrupt management as well. This results in a significant dependency on
289 to a Secure OS which runs in Secure-EL1/Secure-EL0. It interfaces with the
292 which runs only in Secure-EL1.
300 This section describes in detail the role of each software component (see
318 The ``id`` is parameter is reserved and could be used in the future for passing
326 that it was in the non-secure state. A value of ``0`` indicates that it was
327 in the secure state. This bit can be used by the handler to ensure that
334 for the security state specified in the ``flags`` parameter.
342 A portable interrupt handler implementation must set the target context both in
362 is as described in Section 2.
365 ``-EALREADY`` in case a handler for the interrupt type has already been
370 prior to entry into a lower exception level in either security state. The
372 each security state in the ``cpu_context`` structure of each CPU. It exports the
375 in the ``cpu_context`` is used by the ``el3_exit()`` function to program the
391 It is worth noting that in the current implementation of the framework, the EL3
406 type using the ``register_interrupt_type_handler()`` API in EL3 runtime firmware.
410 program the routing model only after SP initialisation has completed e.g. in the
428 - Secure-EL1 interrupts are routed to EL3 when execution is in non-secure
429 state and are routed to the FEL when execution is in the secure state
433 model is used for non-secure interrupts. They are routed to the FEL in
438 non secure interrupts are routed to EL3 when execution is in secure state
440 Secure-EL1. The default routing model is used for non secure interrupts in
443 It performs the following actions in the ``tspd_init()`` function to fulfill the
448 ``tsp_vectors`` in the SP which also includes the handler for Secure-EL1
449 interrupts in the ``sel1_intr_entry`` field. The TSPD passes control to the TSP at
509 in the routing model where **CSS=1 and TEL3=0**. Secure-EL1 interrupts
525 is used to generate non-secure interrupts in either security state.
539 in which it should arrange to return execution to the SP. The SP should
540 provide this information in an implementation defined way during the
543 #. **CSS=1, TEL3=1**. Interrupts are routed to EL3 when execution is in
545 handling model as described in 1. above.
548 is in secure state. They will not be visible to the SP. The ``PSTATE.F`` bit
549 in Secure-EL1/Secure-EL0 will not mask FIQs. The EL3 runtime firmware will
552 synchronous interrupt handling model described in 1. above.
568 resumes in the non-secure state.
571 be visible to the SP. The ``PSTATE.I`` bit in Secure-EL1/Secure-EL0 will
573 handler which should save the SP state correctly and resume execution in
577 #. **CSS=1, TEL3=0**. Non-secure interrupts are handled in the FEL in
590 described in Section `Secure Payload Dispatcher`__. It is known to the TSPD
596 interrupts taken in non-secure state and routed through the TSPD service
606 The TSP also programs the Secure Physical Timer in the Arm Generic Timer block
608 interrupt management across all the software components listed in `Software
614 This section describes in detail the role of each software component (see
615 Section `Software components`_) in handling an interrupt of a particular type.
635 upon exception entry. The registers are saved in the per-cpu ``cpu_context``
638 #. Saving the ``ELR_EL3``, ``SP_EL0`` and ``SPSR_EL3`` system registers in the
642 from the per-cpu ``cpu_context`` data structure in ``SP_EL0`` and
665 described in Section 2. ``NULL`` is returned if no handler has been
678 #. Calling ``el3_exit()`` to return from EL3 into a lower exception level in
696 exception level (passed in the ``flags`` parameter of the handler) where
704 interrupts are routed to S-EL1 when execution is in Secure state, then a
729 interrupt can be routed to EL3 while execution is in the SP. This implies
739 The routing model allows non-secure interrupts to interrupt Secure-EL1 when in
742 exception level in the non-secure state. The former should save the SP context,
751 should handle this secure monitor call so that execution resumes in the
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
765 #. It uses the security state provided in the ``flags`` parameter to ensure
773 ``SPSR_EL3.DAIF`` bits in the secure CPU context. It sets ``x0`` to
776 will be trashed, which is the ``ELR_EL3`` and ``SPSR_EL3``, in order to be able
793 when a Secure-EL1 interrupt is generated when execution is in the non-secure
801 The TSPD service takes the following actions in ``tspd_smc_handler()`` function
805 execution returns to the non-secure state with ``SMC_UNK`` in ``x0``.
808 the secure CPU context (see step 3 above) in case the TSP had been preempted
823 The TSP in Secure-EL1 can be preempted by a non-secure interrupt during
827 interrupts in the system. With ``EL3_EXCEPTION_HANDLING=1`` however, any EL3
832 ``yielding`` SMC in response to the ``TSP_FID_RESUME`` SMC from the normal world.
835 The non-secure interrupt triggered in Secure-EL1 during ``yielding`` SMC
845 handling Secure-EL1 interrupts that triggered while execution was in the normal
850 routing model for non-secure interrupt in secure state is in effect
858 ``SMC_UNK`` in ``x0``. It then invokes ``tspd_handle_sp_preemption()`` for
873 #. ``SMC_PREEMPTED`` is set in x0 and return to non secure state after
879 service takes the following actions in ``tspd_smc_handler()`` function upon
899 it is generated during execution in the TSP with ``PSTATE.I`` = 0 when the
911 chosen (as described in section :ref:`Secure Payload <sp-int-registration>`).
917 normal execution in the SP later e.g. ``SPSR_EL1``, ``ELR_EL1``. After handling
923 non-secure and Secure-EL1 interrupts at the IRQ and FIQ vectors in its exception
926 service to pass control back to the non-secure state in the last known exception
927 level. This will allow the non-secure interrupt to be handled in the non-secure
935 handover agreement described in Section `Test secure payload dispatcher
965 to the TSP in response to an SMC with ``TSP_FID_RESUME`` as the function
990 assuming ``P.STATE.I=0`` in the non secure state :
1009 This is done in a loop till the SMC call succeeds or fails. If a ``yielding``