docs/design/interrupt-framework-design.rst

276    Secure Payload (SP) software which runs in Secure-EL1/Secure-EL0 and is
288 #. Secure Payload (SP). On a production system, the Secure Payload corresponds
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
415 could either be provided to the SPD service at build time or by the SP at
448    ``tsp_vectors`` in the SP which also includes the handler for Secure-EL1
511    TEL3=1**) where the SPD service will hand them to the SP. This is defined
514 The interrupt handling framework implemented by the SP should support one or
520 service at compile time, then the SP should pass this information to the SPD
535    synchronous interrupt handling model. The SP could implement this scenario
539    in which it should arrange to return execution to the SP. The SP should
548    is in secure state. They will not be visible to the SP. The ``PSTATE.F`` bit
560    non-secure state where the interrupt should be handled e.g the SP could
562    service which indicates that the SP execution has been preempted by a
564    service at compile time then the SP could provide it during the
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
578    non-secure state (EL1/EL2) and are not visible to the SP. This routing
579    model does not affect the SP behavior.
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
730    that SP execution can be preempted while handling an interrupt by a
733    priorities before handing control to the SP.
740 secure state if it has been configured to do so. The SPD service and the SP
742 exception level in the non-secure state. The former should save the SP context,
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
909 The SP should implement one or both of the synchronous and asynchronous
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
925 when a non-secure interrupt is generated, the SP should coordinate with the SPD