doc: Add minimal glossary

One of the current issues with the documentation is that terms and
abbreviations are frequently redefined. For example, we might have
a sentence like "... the SCP (System Control Processor) will ...".

These definitions might be repeated several times across pages, or
even within the same document. Equally, some of these abbreviations
are missed and are never expanded.

Sphinx provides a :term: keyword that takes some text and,
if that text is defined in a glossary document, links to its glossary
entry. Using this functionality will prevent repeated definitions
and will make the docs more maintainable by using a single
definition source.

The glossary added in this patch was created from a quick scrub of
the source code - there may be missing entries. The SDEI abbreviation
was used as an example.

Note that a global_substitutions file was created. This file contains
the RST 'replace' statements that convert plain text terms into linked
terms (by adding the ':term:' keyword to them). An example is:

.. |TF-A| replace:: :term:`TF-A`

The 'rst_prolog' variable in conf.py is used to inject this list of
replacements into each page. Terms must be surrounded with the pipe
character to be turned into links - this means that we can still
prevent certain terms from being linked if we don't want them to be.

Change-Id: I87010ed9cfa4a60011a9b4a431b98cb4bb7baa28
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
This commit is contained in:
Paul Beesley 2019-03-13 13:58:02 +00:00
parent 57354abb20
commit 8f62ca7b30
7 changed files with 273 additions and 37 deletions

View File

@ -294,12 +294,12 @@ Changed
- SDEI
- Added support for unconditionally resuming secure world execution after
SDEI event processing completes
|SDEI| event processing completes
SDEI interrupts, although targeting EL3, occur on behalf of the non-secure
|SDEI| interrupts, although targeting EL3, occur on behalf of the non-secure
world, and may have higher priority than secure world
interrupts. Therefore they might preempt secure execution and yield
execution to the non-secure SDEI handler. Upon completion of SDEI event
execution to the non-secure |SDEI| handler. Upon completion of |SDEI| event
handling, resume secure execution if it was preempted.
- Translation Tables (XLAT)
@ -501,7 +501,7 @@ New Features
- Implement dynamic mitigation for CVE-2018-3639 on Cortex-A76
- Ensure SDEI handler executes with CVE-2018-3639 mitigation enabled
- Ensure |SDEI| handler executes with CVE-2018-3639 mitigation enabled
- Introduce RAS handling on AArch64
@ -621,7 +621,7 @@ New Features
- Introduce jump primitives for BL31
- Mask events after CPU wakeup in SDEI dispatcher to conform to the
- Mask events after CPU wakeup in |SDEI| dispatcher to conform to the
specification
- Misc TF-A Core Common Code Enhancements
@ -785,8 +785,8 @@ New features
management and security services. The SPM is the firmware component that
is responsible for managing a Secure Partition.
- SDEI dispatcher: Support for interrupt-based SDEI events and all
interfaces as defined by the SDEI specification v1.0, see
- SDEI dispatcher: Support for interrupt-based |SDEI| events and all
interfaces as defined by the |SDEI| specification v1.0, see
`SDEI Specification`_
- Exception Handling Framework (EHF): Framework that allows dispatching of

View File

@ -1,9 +1,6 @@
Exception Handling Framework
============================
.. |EHF| replace:: Exception Handling Framework
.. |TF-A| replace:: Trusted Firmware-A
This document describes various aspects of handling exceptions by Runtime
Firmware (BL31) that are targeted at EL3, other than SMCs. The |EHF| takes care
of the following exceptions when targeted at EL3:
@ -48,11 +45,11 @@ exceptions are targeted at and handled in EL3. For instance:
- The Arm `SDEI specification`_ defines interfaces through which Normal world
interacts with the Runtime Firmware in order to request notification of
system events. The SDEI specification requires that these events are notified
even when the Normal world executes with the exceptions masked. This too
implies that firmware-first handling is required, where the events are first
received by the EL3 firmware, and then dispatched to Normal world through
purely software mechanism.
system events. The |SDEI| specification requires that these events are
notified even when the Normal world executes with the exceptions masked. This
too implies that firmware-first handling is required, where the events are
first received by the EL3 firmware, and then dispatched to Normal world
through purely software mechanism.
For |TF-A|, firmware-first handling means that asynchronous exceptions are
suitably routed to EL3, and the Runtime Firmware (BL31) is extended to include
@ -73,8 +70,8 @@ choose to:
processing of the error to dedicated software stack running at lower secure
ELs (as above); additionally, the Normal world may also be required to
participate in the handling, or be notified of such events (for example, as
an SDEI event). In this scheme, exception handling potentially and maximally
spans all ELs in both Secure and Normal worlds.
an |SDEI| event). In this scheme, exception handling potentially and
maximally spans all ELs in both Secure and Normal worlds.
On any given system, all of the above handling models may be employed
independently depending on platform choice and the nature of the exception
@ -603,8 +600,8 @@ should carefully consider the assignment of priorities to dispatchers integrated
into runtime firmware. The platform should sensibly delineate priority to
various dispatchers according to their nature. In particular, dispatchers of
critical nature (RAS, for example) should be assigned higher priority than
others (SDEI, for example); and within SDEI, Critical priority SDEI should be
assigned higher priority than Normal ones.
others (|SDEI|, for example); and within |SDEI|, Critical priority
|SDEI| should be assigned higher priority than Normal ones.
Limitations
-----------

View File

@ -9,6 +9,8 @@
#
# See the options documentation at http://www.sphinx-doc.org/en/master/config
import os
# -- Project information -----------------------------------------------------
project = 'Trusted Firmware-A'
@ -16,7 +18,6 @@ project = 'Trusted Firmware-A'
version = '2.1'
release = version # We don't need these to be distinct
# -- General configuration ---------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
@ -48,6 +49,10 @@ exclude_patterns = []
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# Load the contents of the global substitutions file into the 'rst_prolog'
# variable. This ensures that the substitutions are all inserted into each page.
with open('global_substitutions.txt', 'r') as subs:
rst_prolog = subs.read()
# -- Options for HTML output -------------------------------------------------

View File

@ -1840,7 +1840,7 @@ line boundary.
SDEI porting requirements
~~~~~~~~~~~~~~~~~~~~~~~~~
The SDEI dispatcher requires the platform to provide the following macros
The |SDEI| dispatcher requires the platform to provide the following macros
and functions, of which some are optional, and some others mandatory.
Macros
@ -1850,19 +1850,19 @@ Macro: PLAT_SDEI_NORMAL_PRI [mandatory]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This macro must be defined to the EL3 exception priority level associated with
Normal SDEI events on the platform. This must have a higher value (therefore of
lower priority) than ``PLAT_SDEI_CRITICAL_PRI``.
Normal |SDEI| events on the platform. This must have a higher value
(therefore of lower priority) than ``PLAT_SDEI_CRITICAL_PRI``.
Macro: PLAT_SDEI_CRITICAL_PRI [mandatory]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This macro must be defined to the EL3 exception priority level associated with
Critical SDEI events on the platform. This must have a lower value (therefore of
higher priority) than ``PLAT_SDEI_NORMAL_PRI``.
Critical |SDEI| events on the platform. This must have a lower value
(therefore of higher priority) than ``PLAT_SDEI_NORMAL_PRI``.
**Note**: SDEI exception priorities must be the lowest among Secure priorities.
Among the SDEI exceptions, Critical SDEI priority must be higher than Normal
SDEI priority.
**Note**: |SDEI| exception priorities must be the lowest among Secure
priorities. Among the |SDEI| exceptions, Critical |SDEI| priority must
be higher than Normal |SDEI| priority.
Functions
.........
@ -1876,10 +1876,10 @@ Function: int plat_sdei_validate_entry_point(uintptr_t ep) [optional]
Return: int
This function validates the address of client entry points provided for both
event registration and *Complete and Resume* SDEI calls. The function takes one
argument, which is the address of the handler the SDEI client requested to
register. The function must return ``0`` for successful validation, or ``-1``
upon failure.
event registration and *Complete and Resume* |SDEI| calls. The function
takes one argument, which is the address of the handler the |SDEI| client
requested to register. The function must return ``0`` for successful validation,
or ``-1`` upon failure.
The default implementation always returns ``0``. On Arm platforms, this function
is implemented to translate the entry point to physical address, and further to
@ -1894,11 +1894,12 @@ Function: void plat_sdei_handle_masked_trigger(uint64_t mpidr, unsigned int intr
Argument: unsigned int
Return: void
SDEI specification requires that a PE comes out of reset with the events masked.
The client therefore is expected to call ``PE_UNMASK`` to unmask SDEI events on
the PE. No SDEI events can be dispatched until such time.
|SDEI| specification requires that a PE comes out of reset with the events
masked. The client therefore is expected to call ``PE_UNMASK`` to unmask
|SDEI| events on the PE. No |SDEI| events can be dispatched until such
time.
Should a PE receive an interrupt that was bound to an SDEI event while the
Should a PE receive an interrupt that was bound to an |SDEI| event while the
events are masked on the PE, the dispatcher implementation invokes the function
``plat_sdei_handle_masked_trigger``. The MPIDR of the PE that received the
interrupt and the interrupt ID are passed as parameters.

View File

@ -0,0 +1,55 @@
.. |AArch32| replace:: :term:`AArch32`
.. |AArch64| replace:: :term:`AArch64`
.. |API| replace:: :term:`API`
.. |CoT| replace:: :term:`CoT`
.. |COT| replace:: :term:`COT`
.. |CSS| replace:: :term:`CSS`
.. |CVE| replace:: :term:`CVE`
.. |DS-5| replace:: :term:`DS-5`
.. |DT| replace:: :term:`DT`
.. |EL| replace:: :term:`EL`
.. |EHF| replace:: :term:`EHF`
.. |FDT| replace:: :term:`FDT`
.. |FIP| replace:: :term:`FIP`
.. |FVP| replace:: :term:`FVP`
.. |FWU| replace:: :term:`FWU`
.. |GIC| replace:: :term:`GIC`
.. |ISA| replace:: :term:`ISA`
.. |Linaro| replace:: :term:`Linaro`
.. |MMU| replace:: :term:`MMU`
.. |MPAM| replace:: :term:`MPAM`
.. |MPIDR| replace:: :term:`MPIDR`
.. |OEN| replace:: :term:`OEN`
.. |OP-TEE| replace:: :term:`OP-TEE`
.. |OTE| replace:: :term:`OTE`
.. |PDD| replace:: :term:`PDD`
.. |PMF| replace:: :term:`PMF`
.. |PSCI| replace:: :term:`PSCI`
.. |RAS| replace:: :term:`RAS`
.. |ROT| replace:: :term:`ROT`
.. |SCMI| replace:: :term:`SCMI`
.. |SCP| replace:: :term:`SCP`
.. |SDEI| replace:: :term:`SDEI`
.. |SDS| replace:: :term:`SDS`
.. |SEA| replace:: :term:`SEA`
.. |SiP| replace:: :term:`SiP`
.. |SIP| replace:: :term:`SIP`
.. |SMC| replace:: :term:`SMC`
.. |SMCCC| replace:: :term:`SMCCC`
.. |SoC| replace:: :term:`SoC`
.. |SP| replace:: :term:`SP`
.. |SPD| replace:: :term:`SPD`
.. |SPM| replace:: :term:`SPM`
.. |SVE| replace:: :term:`SVE`
.. |TBB| replace:: :term:`TBB`
.. |TBBR| replace:: :term:`TBBR`
.. |TEE| replace:: :term:`TEE`
.. |TF-A| replace:: :term:`TF-A`
.. |TF-M| replace:: :term:`TF-M`
.. |TLB| replace:: :term:`TLB`
.. |TLK| replace:: :term:`TLK`
.. |TSP| replace:: :term:`TSP`
.. |TZC| replace:: :term:`TZC`
.. |UEFI| replace:: :term:`UEFI`
.. |WDOG| replace:: :term:`WDOG`
.. |XLAT| replace:: :term:`XLAT`

177
docs/glossary.rst Normal file
View File

@ -0,0 +1,177 @@
Glossary
========
This glossary provides definitions for terms and abbreviations used in the TF-A
documentation.
You can find additional definitions in the `Arm Glossary`_.
.. glossary::
:sorted:
AArch32
32-bit execution state of the ARMv8 ISA
AArch64
64-bit execution state of the ARMv8 ISA
API
Application Programming Interface
CoT
COT
Chain of Trust
CSS
Compute Sub-System
CVE
Common Vulnerabilities and Exposures. A CVE document is commonly used to
describe a publicly-known security vulnerability.
DS-5
Arm Development Studio 5
DT
Device Tree
EL
Exception Level
EHF
Exception Handling Framework
FDT
Flattened Device Tree
FIP
Firmware Image Package
FVP
Fixed Virtual Platform
FWU
FirmWare Update
GIC
Generic Interrupt Controller
ISA
Instruction Set Architecture
Linaro
A collaborative engineering organization consolidating
and optimizing open source software and tools for the Arm architecture.
MMU
Memory Management Unit
MPAM
Memory Partitioning And Monitoring. An optional Armv8.4 extension.
MPIDR
Multiprocessor Affinity Register
OEN
Owning Entity Number
OP-TEE
Open Portable Trusted Execution Environment. An example of a :term:`TEE`
OTE
Open-source Trusted Execution Environment
PDD
Platform Design Document
PMF
Performance Measurement Framework
PSCI
Power State Coordination Interface
RAS
Reliability, Availability, and Serviceability extensions. A mandatory
extension for the Armv8.2 architecture and later. An optional extension to
the base Armv8 architecture.
ROT
Root of Trust
SCMI
System Control and Management Interface
SCP
System Control Processor
SDEI
Software Delegated Exception Interface
SDS
Shared Data Storage
SEA
Synchronous External Abort
SiP
SIP
Silicon Provider
SMC
Secure Monitor Call
SMCCC
:term:`SMC` Calling Convention
SoC
System on Chip
SP
Secure Partition
SPD
Secure Payload Dispatcher
SPM
Secure Partition Manager
SVE
Scalable Vector Extension
TBB
Trusted Board Boot
TBBR
Trusted Board Boot Requirements
TEE
Trusted Execution Environment
TF-A
Trusted Firmware-A
TF-M
Trusted Firmware-M
TLB
Translation Lookaside Buffer
TLK
Trusted Little Kernel. A Trusted OS from NVIDIA.
TSP
Test Secure Payload
TZC
TrustZone Controller
UEFI
Unified Extensible Firmware Interface
WDOG
Watchdog
XLAT
Translation (abbr.). For example, "XLAT table".
.. _`Arm Glossary`: https://developer.arm.com/support/arm-glossary

View File

@ -15,6 +15,7 @@ Trusted Firmware-A Documentation
security_advisories/index
change-log
acknowledgements
glossary
maintainers
license
@ -102,7 +103,7 @@ Functionality
Secure-EL0, which can be used to implement simple management and
security services.
- An SDEI dispatcher to route interrupt-based SDEI events.
- An |SDEI| dispatcher to route interrupt-based |SDEI| events.
- An Exception Handling Framework (EHF) that allows dispatching of EL3
interrupts to their registered handlers, to facilitate firmware-first