Lines Matching full:the
5 allows EL3 software to configure the interrupt routing behavior. Its main
6 objective is to implement the following two requirements.
10 (normal world). The framework should then take care of handing control of
11 the interrupt to either software in EL3 or Secure-EL1 depending upon the
12 software configuration and the GIC implementation. This requirement ensures
13 that secure interrupts are under the control of the secure software with
14 respect to their delivery and handling without the possibility of
18 non-secure software (Non-secure interrupts) to the last executed exception
19 level in the normal world when the execution is in secure world at
20 exception levels lower than EL3. This could be done with or without the
21 knowledge of software executing in Secure-EL1/Secure-EL0. The choice of
22 approach should be governed by the secure software. This requirement
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
33 the exception level(s) it is handled in.
36 Secure-EL1 depending upon the security state of the current execution
40 Secure-EL1, Non-secure EL1 or EL2 depending upon the security state of the
45 depending upon the security state of the current execution context. It is
48 The following constants define the various interrupt types in the framework
60 A type of interrupt can be either generated as an FIQ or an IRQ. The target
61 exception level of an interrupt type is configured through the FIQ and IRQ bits
62 in the Secure Configuration Register at EL3 (``SCR_EL3.FIQ`` and ``SCR_EL3.IRQ``
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
71 single bit for each security state. A value of ``0`` means that the interrupt
72 should be routed to the FEL. A value of ``1`` means that the interrupt should be
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
82 incorrect as they conflict with the requirements mentioned in Section 1. The
83 following sub-sections describe all the possible routing models and specify
85 for GIC version 3.0 (Arm GICv3) and only the Secure-EL1 and Non-secure interrupt
87 Interrupt Management Framework`_). The terminology used in the following
92 #. **TEL3**. Target Exception Level 3. ``0`` when targeted to the FEL. ``1`` when
98 #. **CSS=0, TEL3=0**. Interrupt is routed to the FEL when execution is in
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
109 the Arm Security Extensions.
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
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
130 former's state is correctly saved by the latter.
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.
158 in EL3 can handle the interrupt.
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
163 the Arm Security Extensions.
167 can handle the interrupt.
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
177 programmed in ``SCR_EL3`` while applying the routing model for a type of
178 interrupt. The platform provides this information through the
179 ``plat_interrupt_type_to_line()`` API (described in the
180 :ref:`Porting Guide`). For example, on the FVP port when the platform uses an
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.
189 interrupt signal, and if any one of the interrupt type sets **TEL3=1** for a
191 that security state. This means that all the other interrupt types using the
192 same interrupt signal will be forced to the same routing model. This should be
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/
196 Secure-EL0, both the EL3 and the non secure interrupt types map to the FIQ
197 signal. So if either one of the interrupt type sets the routing model so
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.
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
217 #. Interrupt management: the following sections describe how interrupts are
218 managed by the interrupt handling framework. This entails:
221 specification of the routing model for a type of interrupt.
224 registered handler when the interrupt is generated.
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
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
248 The ``scr_el3[2]`` field also stores the routing model but as a mapping of 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
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
258 export the interface described in the :ref:`Porting Guide` to enable
261 In the remainder of this document, for the sake of simplicity a Arm GICv2 system
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
269 Roles and responsibilities for interrupt management are sub-divided between the
275 #. Secure Payload Dispatcher (SPD) service. This service interfaces with the
278 A switch is triggered by a Secure Monitor Call and it uses the APIs
279 exported by the Context management library to implement this functionality.
280 Switching execution between the two security states is a requirement for
282 the SPD service. TF-A implements an example Test Secure Payload Dispatcher
285 An SPD service plugs into the EL3 runtime firmware and could be common to
288 #. Secure Payload (SP). On a production system, the Secure Payload corresponds
289 to a Secure OS which runs in Secure-EL1/Secure-EL0. It interfaces with the
295 just like the SPD service.
300 This section describes in detail the role of each software component (see
301 `Software components`_) during the registration of a handler for an interrupt
309 This component declares the following prototype for a handler of an interrupt type.
318 The ``id`` is parameter is reserved and could be used in the future for passing
319 the interrupt id of the highest pending interrupt only if there is a foolproof
320 way of determining the id. Currently it contains ``INTR_ID_UNAVAILABLE``.
322 The ``flags`` parameter contains miscellaneous information as follows.
324 #. Security state, bit[0]. This bit indicates the security state of the lower
325 exception level when the interrupt was generated. A value of ``1`` means
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
328 interrupt was generated and routed as per the routing model specified
331 #. Reserved, bits[31:1]. The remaining bits are reserved for future use.
333 The ``handle`` parameter points to the ``cpu_context`` structure of the current CPU
334 for the security state specified in the ``flags`` parameter.
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
338 ``cpu_context`` structure of the current CPU for the target security state. On
339 AArch64, this return value is currently ignored by the caller as the
340 appropriate ``cpu_context`` to be used is expected to be set by the handler
341 via the context management library APIs.
342 A portable interrupt handler implementation must set the target context both in
343 the structure pointed to by the returned pointer and via the context management
344 library APIs. The handler should treat all error conditions as critical errors
348 The runtime firmware provides the following API for registering a handler for a
351 interrupts. This API also requires the caller to specify the routing model for
352 the type of interrupt.
360 The ``type`` parameter can be one of the three interrupt types listed above i.e.
361 ``INTR_TYPE_S_EL1``, ``INTR_TYPE_NS`` & ``INTR_TYPE_EL3``. The ``flags`` parameter
364 The function will return ``0`` upon a successful registration. It will return
365 ``-EALREADY`` in case a handler for the interrupt type has already been
366 registered. If the ``type`` is unrecognised or the ``flags`` or the ``handler`` are
369 Interrupt routing is governed by the configuration of the ``SCR_EL3.FIQ/IRQ`` bits
370 prior to entry into a lower exception level in either security state. The
371 context management library maintains a copy of the ``SCR_EL3`` system register for
372 each security state in the ``cpu_context`` structure of each CPU. It exports the
373 following APIs to let EL3 Runtime Firmware program and retrieve the routing
374 model for each security state for the current CPU. The value of ``SCR_EL3`` stored
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.
385 ``cm_get_scr_el3()`` returns the value of the ``SCR_EL3`` register for the specified
386 security state of the current CPU. ``cm_write_scr_el3_bit()`` writes a ``0`` or ``1``
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
389 model using the ``cm_get_scr_el3()`` and ``cm_write_scr_el3_bit()`` APIs.
391 It is worth noting that in the current implementation of the framework, the EL3
392 runtime firmware is responsible for programming the routing model. The SPD is
393 responsible for ensuring that the routing model has been adhered to upon
401 A SPD service is responsible for determining and maintaining the interrupt
402 routing model supported by itself and the Secure Payload. It is also responsible
404 the routing model. It could determine the routing model at build time or at
406 type using the ``register_interrupt_type_handler()`` API in EL3 runtime firmware.
408 If the routing model is not known to the SPD service at build time, then it must
409 be provided by the SP as the result of its initialisation. The SPD should
410 program the routing model only after SP initialisation has completed e.g. in the
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
414 after receiving an interrupt from the EL3 runtime firmware. This information
415 could either be provided to the SPD service at build time or by the SP at
423 ``1``, the same results also apply when ``EL3_EXCEPTION_HANDLING`` is ``1``.
425 The TSPD only handles Secure-EL1 interrupts and is provided with the following
429 state and are routed to the FEL when execution is in the secure state
432 - When the build flag ``TSP_NS_INTR_ASYNC_PREEMPT`` is zero, the default routing
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
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
446 #. It passes control to the Test Secure Payload to perform its
447 initialisation. The TSP provides the address of the vector table
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
452 The handover agreement between the TSP and the TSPD requires that the TSPD
454 ``tsp_sel1_intr_entry()``. The TSP has to preserve the callee saved general
458 #. The TSPD implements a handler function for Secure-EL1 interrupts. This
459 function is registered with the EL3 runtime firmware using the
474 #. When the build flag ``TSP_NS_INTR_ASYNC_PREEMPT`` is defined to 1, the TSPD
476 registered with the EL3 runtime firmware using the
498 execution will alternate between the below cases.
500 #. In the code where IRQ, FIQ or both interrupts are enabled, if an interrupt
501 type is targeted to the FEL, then it will be routed to the Secure-EL1
502 exception vector table. This is defined as the **asynchronous mode** of
506 #. In the code where both interrupts are disabled, if an interrupt type is
507 targeted to the FEL, then execution will eventually migrate to the
509 in the routing model where **CSS=1 and TEL3=0**. Secure-EL1 interrupts
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
512 as the **synchronous mode** of handling interrupts.
514 The interrupt handling framework implemented by the SP should support one or
515 both these interrupt handling models depending upon the chosen routing model.
517 The following list briefly describes how the choice of a valid routing model
518 (see `Valid routing models`_) effects the implementation of the Secure-EL1
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
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
535 synchronous interrupt handling model. The SP could implement this scenario
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
538 know the state of the system, general purpose and the ``PSTATE`` registers
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
541 registration phase if it is not known to the SPD service at build time.
544 non-secure state. They should be handled through the synchronous interrupt
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
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
559 IHF should co-ordinate with the SPD service to transfer execution to the
560 non-secure state where the interrupt should be handled e.g the SP could
561 allocate a function identifier to issue a SMC64 or SMC32 to the SPD
562 service which indicates that the SP execution has been preempted by a
563 non-secure interrupt. If this function identifier is not known to the SPD
564 service at compile time then the SP could provide it during the
567 If ``PSTATE.I=1`` then the non-secure interrupt will pend until execution
568 resumes in the non-secure state.
571 be visible to the SP. The ``PSTATE.I`` bit in Secure-EL1/Secure-EL0 will
572 have not effect. The SPD service should register a non-secure interrupt
573 handler which should save the SP state correctly and resume execution in
574 the non-secure state where the interrupt will be handled. The Secure-EL1
577 #. **CSS=1, TEL3=0**. Non-secure interrupts are handled in the FEL in
578 non-secure state (EL1/EL2) and are not visible to the SP. This routing
579 model does not affect the SP behavior.
582 configured at the interrupt controller by the platform port of the EL3 runtime
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
590 described in Section `Secure Payload Dispatcher`__. It is known to the TSPD
595 The TSP implements an entrypoint (``tsp_sel1_intr_entry()``) for handling Secure-EL1
596 interrupts taken in non-secure state and routed through the TSPD service
597 (synchronous handling model). It passes the reference to this entrypoint via
598 ``tsp_vectors`` to the TSPD service.
600 The TSP also replaces the default exception vector table referenced through the
602 exceptions taken at the same (Secure-EL1) exception level. This table is
603 referenced through the ``tsp_exceptions`` variable and programmed into the
604 VBAR_EL1. It caters for the asynchronous handling model.
606 The TSP also programs the Secure Physical Timer in the Arm Generic Timer block
607 to raise a periodic interrupt (every half a second) for the purpose of testing
608 interrupt management across all the software components listed in `Software
614 This section describes in detail the role of each software component (see
620 The EL3 runtime firmware populates the IRQ and FIQ exception vectors referenced
621 by the ``runtime_exceptions`` variable as follows.
623 #. IRQ and FIQ exceptions taken from the current exception level with
625 mentioned earlier, EL3 runtime firmware always executes with the
628 #. The following text describes how the IRQ and FIQ exceptions taken from a
631 When an interrupt is generated, the vector for each interrupt type is
634 #. Saving the entire general purpose register context (x0-x30) immediately
635 upon exception entry. The registers are saved in the per-cpu ``cpu_context``
636 data structure referenced by the ``SP_EL3``\ register.
638 #. Saving the ``ELR_EL3``, ``SP_EL0`` and ``SPSR_EL3`` system registers in the
639 per-cpu ``cpu_context`` data structure referenced by the ``SP_EL3`` register.
641 #. Switching to the C runtime stack by restoring the ``CTX_RUNTIME_SP`` value
642 from the per-cpu ``cpu_context`` data structure in ``SP_EL0`` and
643 executing the ``msr spsel, #0`` instruction.
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
647 vector. The platform should implement the following API to determine the
648 type of the pending interrupt.
656 #. Determining the handler for the type of interrupt that has been generated.
657 The following API has been added for this purpose.
663 It returns the reference to the registered handler for this interrupt
664 type. The ``handler`` is retrieved from the ``intr_type_desc_t`` structure as
669 #. Calling the registered handler function for the interrupt type generated.
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``
676 structure for the target security state.
679 the security state determined by the handler routine. The ``el3_exit()``
680 function is responsible for restoring the register context from the
681 ``cpu_context_t`` data structure for the target security state.
689 The SPD service begins handling an interrupt when the EL3 runtime firmware calls
690 the handler function for that type of interrupt. The SPD service is responsible
691 for the following:
693 #. Validating the interrupt. This involves ensuring that the interrupt was
694 generated according to the interrupt routing model specified by the SPD
695 service during registration. It should use the security state of the
696 exception level (passed in the ``flags`` parameter of the handler) where
697 the interrupt was taken from to determine this. If the interrupt is not
698 recognised then the handler should treat it as an irrecoverable error
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.
708 #. Determining whether a context switch is required. This depends upon the
710 if the security state of the execution context where the interrupt was
711 generated is not the same as the security state required for handling
712 the interrupt, a context switch is required. The following 2 cases
715 #. A Secure-EL1 interrupt taken from the non-secure state should be
716 routed to the Secure Payload.
718 #. A non-secure interrupt taken from the secure state should be routed
719 to the last known non-secure exception level.
721 The SPD service must save the system register context of the current
722 security state. It must then restore the system register context of the
723 target security state. It should use the ``cm_set_next_eret_context()`` API
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
728 per the synchronous interrupt handling model it implements. A Secure-EL1
729 interrupt can be routed to EL3 while execution is in the SP. This implies
731 another higher priority Secure-EL1 interrupt or a EL3 interrupt. The SPD
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
742 exception level in the non-secure state. The former should save the SP context,
743 restore the non-secure context and arrange for entry into the non-secure state
744 so that the interrupt can be handled.
749 When the Secure Payload has finished handling a Secure-EL1 interrupt, it could
750 return control back to the SPD service through a SMC32 or SMC64. The SPD service
751 should handle this secure monitor call so that execution resumes in the
752 exception level and the security state from where the Secure-EL1 interrupt was
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
762 originating from the non-secure state. It takes the following actions upon being
765 #. It uses the security state provided in the ``flags`` parameter to ensure
766 that the secure interrupt originated from the non-secure state. It asserts
767 if this is not the case.
769 #. It saves the system register context for the non-secure state by calling
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
774 ``TSP_HANDLE_SEL1_INTR_AND_RETURN``. If the TSP was preempted earlier by a non
775 secure interrupt during ``yielding`` SMC processing, save the registers that
776 will be trashed, which is the ``ELR_EL3`` and ``SPSR_EL3``, in order to be able
778 save any other secure context since the TSP is expected to preserve it
781 #. It restores the system register context for the secure state by calling
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
788 now be handled by the SP. ``x1`` is written with the value of ``elr_el3``
789 register for the non-secure state. This information is used by the SP for
792 The figure below describes how the interrupt handling is implemented by the TSPD
793 when a Secure-EL1 interrupt is generated when execution is in the non-secure
798 The TSP issues an SMC with ``TSP_HANDLED_S_EL1_INTR`` as the function identifier to
801 The TSPD service takes the following actions in ``tspd_smc_handler()`` function
802 upon receiving an SMC with ``TSP_HANDLED_S_EL1_INTR`` as the function identifier:
804 #. It ensures that the call originated from the secure state otherwise
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
808 the secure CPU context (see step 3 above) in case the TSP had been preempted
811 #. It restores the system register context for the non-secure state by
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``
818 as the return value.
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
830 It should be noted that while TSP is preempted, the TSPD only allows entry into
831 the TSP either for Secure-EL1 interrupt handling or for resuming the preempted
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
838 dispatcher behavior`_). If the build option is set, the TSPD will set the
839 routing model for the non-secure interrupt to be routed to EL3 from secure state
840 i.e. **TEL3=1, CSS=0** and registers ``tspd_ns_interrupt_handler()`` as the
841 non-secure interrupt handler. The ``tspd_ns_interrupt_handler()`` on being
842 invoked ensures that the interrupt originated from the secure state and disables
845 handling Secure-EL1 interrupts that triggered while execution was in the normal
846 world. The ``tspd_ns_interrupt_handler()`` then invokes
849 If the ``TSP_NS_INTR_ASYNC_PREEMPT`` build option is zero (default), the default
851 i.e. **TEL3=0, CSS=0**. During ``yielding`` SMC processing, the IRQ
853 trigger at Secure-EL1 IRQ exception vector. The TSP saves the general purpose
854 register context and issues an SMC with ``TSP_PREEMPTED`` as the function
855 identifier to signal preemption of TSP. The TSPD SMC handler,
856 ``tspd_smc_handler()``, ensures that the SMC call originated from the
857 secure state otherwise execution returns to the non-secure state with
861 The ``tspd_handle_sp_preemption()`` takes the following actions upon being
864 #. It saves the system register context for the secure state by calling
867 #. It restores the system register context for the non-secure state by
870 #. It ensures that the non-secure CPU context is used to program the next
876 The Normal World is expected to resume the TSP after the ``yielding`` SMC
877 preemption by issuing an SMC with ``TSP_FID_RESUME`` as the function identifier
878 (see section `Implication of preempted SMC on Non-Secure Software`_). The TSPD
879 service takes the following actions in ``tspd_smc_handler()`` function upon
882 #. It ensures that the call originated from the non secure state. An
885 #. Checks whether the TSP needs a resume i.e check if it was preempted. It
886 then saves the system register context for the non-secure state by calling
889 #. Restores the secure context by calling
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
898 The figure below describes how the TSP/TSPD handle a non-secure interrupt when
899 it is generated during execution in the TSP with ``PSTATE.I`` = 0 when the
909 The SP should implement one or both of the synchronous and asynchronous
910 interrupt handling models depending upon the interrupt routing model it has
913 In the synchronous model, it should begin handling a Secure-EL1 interrupt after
914 receiving control from the SPD service at an entrypoint agreed upon during build
915 time or during the registration phase. Before handling the interrupt, the SP
917 normal execution in the SP later e.g. ``SPSR_EL1``, ``ELR_EL1``. After handling
918 the interrupt, the SP could return control back to the exception level and
919 security state where the interrupt was originally taken from. The SP should use
920 an SMC32 or SMC64 to ask the SPD service to do this.
922 In the asynchronous model, the Secure Payload is responsible for handling
923 non-secure and Secure-EL1 interrupts at the IRQ and FIQ vectors in its exception
925 when a non-secure interrupt is generated, the SP should coordinate with the SPD
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
934 ``tsp_sel1_intr_entry()``. The TSP handles the interrupt while ensuring that the
940 #. Checks whether the interrupt is the secure physical timer interrupt. It
941 uses the platform API ``plat_ic_get_pending_interrupt_id()`` to get the
942 interrupt number. If it is not the secure physical timer interrupt, then
945 an SMC with ``TSP_PREEMPTED`` as the function identifier.
947 #. Handles the secure timer interrupt interrupt by acknowledging it using the
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
954 ``TSP_HANDLED_S_EL1_INTR`` as the function identifier.
956 The TSP handles interrupts under the asynchronous model as follows.
958 #. Secure-EL1 interrupts are handled by calling the ``tsp_common_int_handler()``
959 function. The function has been described above.
961 #. Non-secure interrupts are handled by calling the ``tsp_common_int_handler()``
963 SMC64 with ``TSP_PREEMPTED`` as the function identifier. Execution resumes at
964 the instruction that follows this SMC instruction when the TSPD hands control
965 to the TSP in response to an SMC with ``TSP_FID_RESUME`` as the function
966 identifier from the non-secure state (see section `Test secure payload
976 interrupt and the execution can return to the non-secure world for handling
977 the interrupt (For details on ``yielding`` SMC refer `SMC calling convention`_).
978 In this case, the SMC call has not completed its execution and the execution
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
986 In the Test Secure Payload implementation, ``TSP_FID_RESUME`` is designated
987 as the resume SMC FID. It is important to note that ``TSP_FID_RESUME`` is a
988 ``yielding`` SMC which means it too can be be preempted. The typical non
990 assuming ``P.STATE.I=0`` in the non secure state :
996 /* The pending non-secure interrupt is handled by the interrupt handler
998 while (rc == SMC_PREEMPTED) { /* Check if the SMC call is preempted */
1002 The ``TSP_YIELD_SMC_FID`` is any ``yielding`` SMC function identifier and the smc()
1003 function invokes a SMC call with the required arguments. The pending non-secure
1004 interrupt causes an IRQ exception and the IRQ handler registered at the
1005 exception vector handles the non-secure interrupt and returns. The return value
1006 from the SMC call is tested for ``SMC_PREEMPTED`` to check whether it is
1007 preempted. If it is, then the resume SMC call ``TSP_FID_RESUME`` is issued. The
1008 return value of the SMC call is tested again to check if it is preempted.
1009 This is done in a loop till the SMC call succeeds or fails. If a ``yielding``
1011 completed, the current TSPD prevents any other SMC call from re-entering