Lines Matching refs:to
4 This framework is responsible for managing interrupts routed to EL3. It also
5 allows EL3 software to configure the interrupt routing behavior. Its main
6 objective is to implement the following two requirements.
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
11 the interrupt to either software in EL3 or Secure-EL1 depending upon the
14 respect to their delivery and handling without the possibility of
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
23 ensures that non-secure software is able to execute in tandem with the
32 The framework categorises an interrupt to be one of the following depending upon
35 #. Secure EL1 interrupt. This type of interrupt can be routed to EL3 or
39 #. Non-secure interrupt. This type of interrupt can be routed to EL3,
44 #. EL3 interrupt. This type of interrupt can be routed to EL3 or Secure-EL1
63 bits). When ``SCR_EL3.FIQ``\ =1, FIQs are routed to EL3. Otherwise they are routed
64 to the First Exception Level (FEL) capable of handling interrupts. When
65 ``SCR_EL3.IRQ``\ =1, IRQs are routed to EL3. Otherwise they are routed to the
67 state prior to entry into a lower exception level in that security state.
72 should be routed to the FEL. A value of ``1`` means that the interrupt should be
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
81 The framework considers certain routing models for each type of interrupt to be
92 #. **TEL3**. Target Exception Level 3. ``0`` when targeted to the FEL. ``1`` when
93 targeted to EL3.
98 #. **CSS=0, TEL3=0**. Interrupt is routed to the FEL when execution is in
102 #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in secure
104 handover the interrupt to Secure-EL1 for handling.
106 #. **CSS=1, TEL3=0**. Interrupt is routed to the FEL when execution is in
108 is not visible to the secure software which violates the motivation behind
111 #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
113 can handover the interrupt to Secure-EL1 for handling.
118 #. **CSS=0, TEL3=0**. Interrupt is routed to the FEL when execution is in
119 secure state. This allows the secure software to trap non-secure
120 interrupts, perform its book-keeping and hand the interrupt to the
125 #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in secure
128 interrupt to non-secure software. This model requires additional
129 coordination between Secure-EL1 and EL3 software to ensure that 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
138 reason to route the interrupt to EL3 software and then hand it back to
146 #. **CSS=0, TEL3=0**. Interrupt is routed to the FEL when execution is in
149 by EL3 interrupt and can handover the interrupt to EL3 for handling.
152 invalid as EL3 interrupts are unconditionally routed to EL3, and EL3
156 #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in
160 #. **CSS=1, TEL3=0**. Interrupt is routed to the FEL when execution is in
162 is not visible to the secure software which violates the motivation behind
165 #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
169 Mapping of interrupt type to signal
172 The framework is meant to work with any interrupt controller implemented by a
174 FIQ or IRQ signal to the CPU depending upon the current security state. The
175 mapping between the type and signal is known only to the platform. The framework
176 uses this information to determine whether the IRQ or the FIQ bit should be
185 Effect of mapping of several interrupt types to one signal
188 It should be noted that if more than one interrupt type maps to a single
190 particular security state, then interrupt signal will be routed to EL3 when in
192 same interrupt signal will be forced to the same routing model. This should be
196 Secure-EL0, both the EL3 and the non secure interrupt types map to the FIQ
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
200 effectively routing the other interrupt type also to EL3.
205 The framework makes the following assumptions to simplify its implementation.
210 Group 0 interrupts. In Arm GICv2, all secure interrupts are assumed to be
211 handled in Secure-EL1. They can be delivered to Secure-EL1 via EL3 but they
220 #. Providing an interface to allow registration of a handler and
223 #. Implementing support to hand control of an interrupt type to its
227 software stack spanning from EL3 to Secure-EL1. These components are described
243 the interrupt should be targeted to the FEL. A value of ``1`` implies that it
244 should be targeted to EL3. The remaining bits are reserved and SBZ. The helper
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
252 The framework also depends upon the platform port to configure the interrupt
253 controller to distinguish between secure and non-secure interrupts. The platform
254 is expected to be aware of the secure devices present in the system and their
255 associated interrupt numbers. It should configure the interrupt controller to
257 the non-secure interrupts and target them to the primary CPU. It should also
258 export the interface described in the :ref:`Porting Guide` to enable
262 is considered and it is assumed that the FIQ signal is used to generate Secure-EL1
263 interrupts and the IRQ signal is used to generate non-secure interrupts in either
273 #. EL3 Runtime Firmware. This component is common to all ports of TF-A.
279 exported by the Context management library to implement this functionality.
285 An SPD service plugs into the EL3 runtime firmware and could be common to
289 to a Secure OS which runs in Secure-EL1/Secure-EL0. It interfaces with the
290 SPD service to manage communication with non-secure software. TF-A
294 A Secure payload implementation could be common to some ports of TF-A,
327 in the secure state. This bit can be used by the handler to ensure that
333 The ``handle`` parameter points to the ``cpu_context`` structure of the current CPU
336 Once the handler routine completes, execution will return to either the secure
337 or non-secure state. The handler routine must return a pointer to
340 appropriate ``cpu_context`` to be used is expected to be set by the handler
343 the structure pointed to by the returned pointer and via the context management
350 this API to register a handler for Secure-EL1 and optionally for non-secure
351 interrupts. This API also requires the caller to specify the routing model for
370 prior to entry into a lower exception level in either security state. The
373 following APIs to let EL3 Runtime Firmware program and retrieve the routing
375 in the ``cpu_context`` is used by the ``el3_exit()`` function to program the
376 ``SCR_EL3`` register prior to returning from the EL3 exception level.
387 to the bit specified by ``bit_pos``. ``register_interrupt_type_handler()`` invokes
388 ``set_routing_model()`` API which programs the ``SCR_EL3`` according to the routing
393 responsible for ensuring that the routing model has been adhered to upon
405 runtime. It must use this information to register a handler for each interrupt
408 If the routing model is not known to the SPD service at build time, then it must
411 SPD initialisation function pointed to by the ``bl32_init`` variable.
413 The SPD should determine the mechanism to pass control to the Secure Payload
415 could either be provided to the SPD service at build time or by the SP at
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
437 - When the build flag ``TSP_NS_INTR_ASYNC_PREEMPT`` is defined to 1, then the
438 non secure interrupts are routed to EL3 when execution is in secure state
443 It performs the following actions in the ``tspd_init()`` function to fulfill the
446 #. It passes control to the Test Secure Payload to perform its
449 interrupts in the ``sel1_intr_entry`` field. The TSPD passes control to the TSP at
454 ``tsp_sel1_intr_entry()``. The TSP has to preserve the callee saved general
456 ``x0-x18`` to enable its C runtime.
474 #. When the build flag ``TSP_NS_INTR_ASYNC_PREEMPT`` is defined to 1, the TSPD
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
507 targeted to the FEL, then execution will eventually migrate to the
510 will be routed to EL3 (as per the routing model where **CSS=1 and
511 TEL3=1**) where the SPD service will hand them to the SP. This is defined
519 IHF. If the choice of the interrupt routing model is not known to the SPD
520 service at compile time, then the SP should pass this information to the SPD
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.
536 by exporting a separate entrypoint for Secure-EL1 interrupts to the SPD
537 service during the registration phase. The SPD service would also need to
539 in which it should arrange to return execution to the SP. The SP should
541 registration phase if it is not known to the SPD service at build time.
543 #. **CSS=1, TEL3=1**. Interrupts are routed to EL3 when execution is in
547 #. **CSS=0, TEL3=1**. Secure-EL1 interrupts are routed to EL3 when execution
548 is in secure state. They will not be visible to the SP. The ``PSTATE.F`` bit
559 IHF should co-ordinate with the SPD service to transfer execution to the
561 allocate a function identifier to issue a SMC64 or SMC32 to the SPD
563 non-secure interrupt. If this function identifier is not known to the SPD
570 #. **CSS=0, TEL3=1**. Non-secure interrupts are routed to EL3. They will not
571 be visible to the SP. The ``PSTATE.I`` bit in Secure-EL1/Secure-EL0 will
575 IHF does not need to take any action.
578 non-secure state (EL1/EL2) and are not visible to the SP. This routing
590 described in Section `Secure Payload Dispatcher`__. It is known to the TSPD
597 (synchronous handling model). It passes the reference to this entrypoint via
598 ``tsp_vectors`` to the TSPD service.
607 to raise a periodic interrupt (every half a second) for the purpose of testing
641 #. Switching to the C runtime stack by restoring the ``CTX_RUNTIME_SP`` value
647 vector. The platform should implement the following API to determine the
663 It returns the reference to the registered handler for this interrupt
670 The ``id`` parameter is set to ``INTR_ID_UNAVAILABLE`` currently. The id along
671 with the current security state and a reference to the ``cpu_context_t``
672 structure for the current security state are passed to the handler function
675 The handler function returns a reference to the per-cpu ``cpu_context_t``
678 #. Calling ``el3_exit()`` to return from EL3 into a lower exception level in
694 generated according to the interrupt routing model specified by the SPD
697 the interrupt was taken from to determine this. If the interrupt is not
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
705 S-EL1 interrupt should never be routed to EL3 from secure state. The handler
706 could use the security state flag to check this.
713 require a context switch from secure to non-secure or vice-versa:
716 routed to the Secure Payload.
719 to the last known non-secure exception level.
724 to ensure that the next ``cpu_context`` to be restored is of the target
727 If the target state is secure then execution should be handed to the SP as
729 interrupt can be routed to EL3 while execution is in the SP. This implies
732 service should be able to handle this preemption or manage secure interrupt
733 priorities before handing control to the SP.
735 #. Setting the return value of the handler to the per-cpu ``cpu_context`` if
736 the interrupt has been successfully validated and ready to be handled at a
739 The routing model allows non-secure interrupts to interrupt Secure-EL1 when in
740 secure state if it has been configured to do so. The SPD service and the SP
741 should implement a mechanism for routing these interrupts to the last known
750 return control back to the SPD service through a SMC32 or SMC64. The SPD service
761 ``tspd_secure_el1_interrupt_handler()`` expects only to be invoked for Secure-EL1
765 #. It uses the security state provided in the ``flags`` parameter to ensure
772 #. It sets the ``ELR_EL3`` system register to ``tsp_sel1_intr_entry`` and sets the
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
777 to re-enter TSP for Secure-EL1 interrupt processing. It does not need to
778 save any other secure context since the TSP is expected to preserve it
784 #. It ensures that the secure CPU context is used to program the next
787 #. It returns the per-cpu ``cpu_context`` to indicate that the interrupt can
798 The TSP issues an SMC with ``TSP_HANDLED_S_EL1_INTR`` as the function identifier to
805 execution returns to the non-secure state with ``SMC_UNK`` in ``x0``.
807 #. It restores the saved ``ELR_EL3`` and ``SPSR_EL3`` system registers back to
814 #. It ensures that the non-secure CPU context is used to program the next
817 #. ``tspd_smc_handler()`` returns a reference to the non-secure ``cpu_context``
832 ``yielding`` SMC in response to the ``TSP_FID_RESUME`` SMC from the normal world.
836 processing can be routed to either EL3 or Secure-EL1 and is controlled by build
839 routing model for the non-secure interrupt to be routed to EL3 from secure state
843 routing of non-secure interrupts from secure state to EL3. This is to prevent
855 identifier to signal preemption of TSP. The TSPD SMC handler,
857 secure state otherwise execution returns to the non-secure state with
870 #. It ensures that the non-secure CPU context is used to program the next
873 #. ``SMC_PREEMPTED`` is set in x0 and return to non secure state after
876 The Normal World is expected to resume the TSP after the ``yielding`` SMC
892 #. It ensures that the secure CPU context is used to program the next
895 #. ``tspd_smc_handler()`` returns a reference to the secure ``cpu_context`` as the
918 the interrupt, the SP could return control back to the exception level and
920 an SMC32 or SMC64 to ask the SPD service to do this.
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
933 The TSPD hands control of a Secure-EL1 interrupt to the TSP at the
941 uses the platform API ``plat_ic_get_pending_interrupt_id()`` to get the
944 ``tsp_handle_preemption()`` to handover control back to EL3 by issuing
949 ``tsp_generic_timer_handler()`` to reprogram the secure physical generic
950 timer and calling the ``plat_ic_end_of_interrupt()`` platform API to signal
953 The TSP passes control back to the TSPD by issuing an SMC64 with
965 to the TSP in response to an SMC with ``TSP_FID_RESUME`` as the function
975 A ``yielding`` SMC call to Secure payload can be preempted by a non-secure
976 interrupt and the execution can return to the non-secure world for handling
979 must return back to the secure payload to resume the preempted SMC call.
980 This can be achieved by issuing an SMC call which instructs to resume the
987 as the resume SMC FID. It is important to note that ``TSP_FID_RESUME`` is a
1006 from the SMC call is tested for ``SMC_PREEMPTED`` to check whether it is
1008 return value of the SMC call is tested again to check if it is preempted.