diff --git a/docs/components/debugfs-design.rst b/docs/components/debugfs-design.rst index 2096bdbb7..253651513 100644 --- a/docs/components/debugfs-design.rst +++ b/docs/components/debugfs-design.rst @@ -80,8 +80,8 @@ SMC interface The communication with the 9p layer in BL31 is made through an SMC conduit (`SMC Calling Convention`_), using a specific SiP Function Id. An NS shared buffer is used to pass path string parameters, or e.g. to exchange -data on a read operation. Refer to `ARM SiP Services`_ for a description -of the SMC interface. +data on a read operation. Refer to :ref:`ARM SiP Services ` +for a description of the SMC interface. Security considerations ----------------------- diff --git a/docs/components/exception-handling.rst b/docs/components/exception-handling.rst index 4c63a8b47..86ed87ce4 100644 --- a/docs/components/exception-handling.rst +++ b/docs/components/exception-handling.rst @@ -10,13 +10,9 @@ of the following exceptions when targeted at EL3: - Asynchronous External Aborts |TF-A|'s handling of synchronous ``SMC`` exceptions raised from lower ELs is -described in the `Firmware Design document`__. However, the |EHF| changes the -semantics of `interrupt handling`__ and `synchronous exceptions`__ other than -SMCs. - -.. __: firmware-design.rst#handling-an-smc -.. __: `Interrupt handling`_ -.. __: `Effect on SMC calls`_ +described in the :ref:`Firmware Design document `. However, the +|EHF| changes the semantics of `Interrupt handling`_ and :ref:`synchronous +exceptions ` other than SMCs. The |EHF| is selected by setting the build option ``EL3_EXCEPTION_HANDLING`` to ``1``, and is only available for AArch64 systems. @@ -77,10 +73,9 @@ On any given system, all of the above handling models may be employed independently depending on platform choice and the nature of the exception received. -.. [#spd] Not to be confused with `Secure Payload Dispatcher`__, which is an - EL3 component that operates in EL3 on behalf of Secure OS. - -.. __: firmware-design.rst#secure-el1-payloads-and-dispatchers +.. [#spd] Not to be confused with :ref:`Secure Payload Dispatcher + `, which is an EL3 component that operates in EL3 + on behalf of Secure OS. The role of Exception Handling Framework ---------------------------------------- @@ -139,6 +134,8 @@ unstacked in strictly the reverse order. For interrupts, the GIC ensures this is the case; for non-interrupts, the |EHF| monitors and asserts this. See `Transition of priority levels`_. +.. _interrupt-handling: + Interrupt handling ------------------ @@ -151,15 +148,12 @@ implications: sufficient priority are signalled as FIQs, and therefore will be routed to EL3. As a result, S-EL1 software cannot expect to handle Non-secure interrupts at S-EL1. Essentially, this deprecates the routing mode described - as `CSS=0, TEL3=0`__. - - .. __: interrupt-framework-design.rst#el3-interrupts + as :ref:`CSS=0, TEL3=0 `. In order for S-EL1 software to handle Non-secure interrupts while having |EHF| enabled, the dispatcher must adopt a model where Non-secure interrupts - are received at EL3, but are then `synchronously`__ handled over to S-EL1. - - .. __: interrupt-framework-design.rst#secure-payload + are received at EL3, but are then :ref:`synchronously ` + handled over to S-EL1. - On GICv2 systems, it's required that the build option ``GICV2_G0_FOR_EL3`` is set to ``1`` so that *Group 0* interrupts target EL3. @@ -283,15 +277,13 @@ The interrupt handler should have the following signature: typedef int (*ehf_handler_t)(uint32_t intr_raw, uint32_t flags, void *handle, void *cookie); -The parameters are as obtained from the top-level `EL3 interrupt handler`__. +The parameters are as obtained from the top-level :ref:`EL3 interrupt handler +`. -.. __: interrupt-framework-design.rst#el3-runtime-firmware - -The `SDEI dispatcher`__, for example, expects the platform to allocate two -different priority levels—``PLAT_SDEI_CRITICAL_PRI``, and -``PLAT_SDEI_NORMAL_PRI``—and registers the same handler to handle both levels. - -.. __: sdei.rst +The :ref:`SDEI dispatcher`, for +example, expects the platform to allocate two different priority levels— +``PLAT_SDEI_CRITICAL_PRI``, and ``PLAT_SDEI_NORMAL_PRI`` —and registers the +same handler to handle both levels. Interrupt handling example -------------------------- @@ -374,11 +366,9 @@ Activating and Deactivating priorities A priority level is said to be *active* when an exception of that priority is being handled: for interrupts, this is implied when the interrupt is -acknowledged; for non-interrupt exceptions, such as SErrors or `SDEI explicit -dispatches`__, this has to be done via calling ``ehf_activate_priority()``. See -`Run-time flow`_. - -.. __: sdei.rst#explicit-dispatch-of-events +acknowledged; for non-interrupt exceptions, such as SErrors or :ref:`SDEI +explicit dispatches `, this has to be done via +calling ``ehf_activate_priority()``. See `Run-time flow`_. Conversely, when the dispatcher has reached a logical resolution for the cause of the exception, the corresponding priority level ought to be deactivated. As @@ -457,6 +447,8 @@ calls to these APIs are subject to the following conditions: If these are violated, a panic will result. +.. _Effect on SMC calls: + Effect on SMC calls ------------------- @@ -542,10 +534,8 @@ The following is an example flow for interrupts: interrupts belonging to different dispatchers. #. The |EHF|, during its initialisation, registers a top-level interrupt handler - with the `Interrupt Management Framework`__ for EL3 interrupts. This also - results in setting the routing bits in ``SCR_EL3``. - - .. __: interrupt-framework-design.rst#el3-runtime-firmware + with the :ref:`Interrupt Management Framework` for EL3 + interrupts. This also results in setting the routing bits in ``SCR_EL3``. #. When an interrupt belonging to a dispatcher fires, GIC raises an EL3/Group 0 interrupt, and is taken to EL3. diff --git a/docs/components/platform-interrupt-controller-API.rst b/docs/components/platform-interrupt-controller-API.rst index 9d02f45c0..069c87b84 100644 --- a/docs/components/platform-interrupt-controller-API.rst +++ b/docs/components/platform-interrupt-controller-API.rst @@ -286,6 +286,8 @@ inserts to order memory updates before updating mask, then writes to the GIC *Priority Mask Register*, and make sure memory updates are visible before potential trigger due to mask update. +.. _plat_ic_get_interrupt_id: + Function: unsigned int plat_ic_get_interrupt_id(unsigned int raw); [optional] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/components/sdei.rst b/docs/components/sdei.rst index c5275a0b7..60259c830 100644 --- a/docs/components/sdei.rst +++ b/docs/components/sdei.rst @@ -205,6 +205,8 @@ will only allow SDEI calls to be made from: See the function ``sdei_client_el()`` in ``sdei_private.h``. +.. _explicit-dispatch-of-events: + Explicit dispatch of events --------------------------- diff --git a/docs/components/secure-partition-manager-mm.rst b/docs/components/secure-partition-manager-mm.rst index 87fc91df3..d53290102 100644 --- a/docs/components/secure-partition-manager-mm.rst +++ b/docs/components/secure-partition-manager-mm.rst @@ -6,11 +6,9 @@ Foreword Two implementations of a Secure Partition Manager co-exist in the TF-A codebase: -- SPM based on the PSA FF-A specification (`Secure Partition Manager`__). +- SPM based on the PSA FF-A specification (:ref:`Secure Partition Manager`). - SPM based on the MM interface. -.. __: secure-partition-manager.html - Both implementations differ in their architectures and only one can be selected at build time. diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst index 2169f30a0..e09da53f3 100644 --- a/docs/components/secure-partition-manager.rst +++ b/docs/components/secure-partition-manager.rst @@ -833,9 +833,7 @@ References .. _[2]: -[2] `Secure Partition Manager using MM interface`__ - -.. __: secure-partition-manager-mm.html +[2] :ref:`Secure Partition Manager using MM interface` .. _[3]: diff --git a/docs/design/firmware-design.rst b/docs/design/firmware-design.rst index ae6dd469d..a357d5858 100644 --- a/docs/design/firmware-design.rst +++ b/docs/design/firmware-design.rst @@ -957,6 +957,8 @@ Function ID call type and OEN onto a specific service handler in the |Image 1| +.. _handling-an-smc: + Handling an SMC ~~~~~~~~~~~~~~~ @@ -1300,6 +1302,8 @@ In other words, the reset handler should be able to detect whether an action has already been performed and act as appropriate. Possible courses of actions are, e.g. skip the action the second time, or undo/redo it. +.. _configuring-secure-interrupts: + Configuring secure interrupts ----------------------------- diff --git a/docs/design/interrupt-framework-design.rst b/docs/design/interrupt-framework-design.rst index 2e200aa3f..dfb2eac8e 100644 --- a/docs/design/interrupt-framework-design.rst +++ b/docs/design/interrupt-framework-design.rst @@ -150,10 +150,8 @@ EL3 interrupts However, when ``EL3_EXCEPTION_HANDLING`` is ``1``, this routing model is invalid as EL3 interrupts are unconditionally routed to EL3, and EL3 - interrupts will always preempt Secure EL1/EL0 execution. See `exception - handling`__ documentation. - - .. __: exception-handling.rst#interrupt-handling + interrupts will always preempt Secure EL1/EL0 execution. See :ref:`exception + handling` documentation. #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in Secure-EL1/Secure-EL0. This is a valid routing model as secure software @@ -303,6 +301,8 @@ This section describes in detail the role of each software component (see `Software components`_) during the registration of a handler for an interrupt type. +.. _el3-runtime-firmware: + EL3 runtime firmware ~~~~~~~~~~~~~~~~~~~~ @@ -901,14 +901,14 @@ it is generated during execution in the TSP with ``PSTATE.I`` = 0 when the |Image 2| -Secure payload -~~~~~~~~~~~~~~ +.. _sp-synchronous-int: + +Secure payload interrupt handling +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The SP should implement one or both of the synchronous and asynchronous interrupt handling models depending upon the interrupt routing model it has -chosen (as described in section `Secure Payload`__). - -.. __: #sp-int-registration +chosen (as described in section :ref:`Secure Payload `). In the synchronous model, it should begin handling a Secure-EL1 interrupt after receiving control from the SPD service at an entrypoint agreed upon during build diff --git a/docs/getting_started/build-options.rst b/docs/getting_started/build-options.rst index 630d86119..b15ea1b52 100644 --- a/docs/getting_started/build-options.rst +++ b/docs/getting_started/build-options.rst @@ -346,16 +346,14 @@ Common build options - ``GICV2_G0_FOR_EL3``: Unlike GICv3, the GICv2 architecture doesn't have inherent support for specific EL3 type interrupts. Setting this build option to ``1`` assumes GICv2 *Group 0* interrupts are expected to target EL3, both - by `platform abstraction layer`__ and `Interrupt Management Framework`__. + by :ref:`platform abstraction layer` and + :ref:`Interrupt Management Framework`. This allows GICv2 platforms to enable features requiring EL3 interrupt type. This also means that all GICv2 Group 0 interrupts are delivered to EL3, and the Secure Payload interrupts needs to be synchronously handed over to Secure EL1 for handling. The default value of this option is ``0``, which means the Group 0 interrupts are assumed to be handled by Secure EL1. - .. __: platform-interrupt-controller-API.rst - .. __: interrupt-framework-design.rst - - ``HANDLE_EA_EL3_FIRST``: When set to ``1``, External Aborts and SError Interrupts will be always trapped in EL3 i.e. in BL31 at runtime. When set to ``0`` (default), these exceptions will be trapped in the current exception diff --git a/docs/getting_started/porting-guide.rst b/docs/getting_started/porting-guide.rst index 7aaeae2f4..6b8bbc634 100644 --- a/docs/getting_started/porting-guide.rst +++ b/docs/getting_started/porting-guide.rst @@ -2482,9 +2482,7 @@ FVP can be configured to use either GICv2 or GICv3 depending on the build flag ``FVP_USE_GIC_DRIVER`` (See :ref:`build_options_arm_fvp_platform` for more details). -See also: `Interrupt Controller Abstraction APIs`__. - -.. __: ../design/platform-interrupt-controller-API.rst +See also: :ref:`Interrupt Controller Abstraction APIs`. Function : plat_interrupt_type_to_line() [mandatory] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2609,9 +2607,7 @@ This API is used by the CPU to indicate to the platform IC that processing of the highest pending interrupt has begun. It should return the raw, unmodified value obtained from the interrupt controller when acknowledging an interrupt. The actual interrupt number shall be extracted from this raw value using the API -`plat_ic_get_interrupt_id()`__. - -.. __: ../design/platform-interrupt-controller-API.rst#function-unsigned-int-plat-ic-get-interrupt-id-unsigned-int-raw-optional +`plat_ic_get_interrupt_id()`. This function in Arm standard platforms using GICv2, reads the *Interrupt Acknowledge Register* (``GICC_IAR``). This changes the state of the highest diff --git a/docs/plat/arm/fvp/index.rst b/docs/plat/arm/fvp/index.rst index fd658bbff..745e31f9e 100644 --- a/docs/plat/arm/fvp/index.rst +++ b/docs/plat/arm/fvp/index.rst @@ -635,7 +635,7 @@ boot Linux with 4 CPUs using the AArch32 build of TF-A. *Copyright (c) 2019-2020, Arm Limited. All rights reserved.* -.. _TB_FW_CONFIG for FVP: ../plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts +.. _TB_FW_CONFIG for FVP: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts .. _Arm's website: `FVP models`_ .. _FVP models: https://developer.arm.com/products/system-design/fixed-virtual-platforms .. _Linaro Release 19.06: http://releases.linaro.org/members/arm/platforms/19.06