aboutsummaryrefslogtreecommitdiff
path: root/documentation
diff options
context:
space:
mode:
authorDavid Wang <david.wang@arm.com>2016-12-12 16:06:17 +0800
committerDavid Wang <david.wang@arm.com>2017-02-28 15:59:37 +0800
commit5acb1bc6e8ece254ffe7dbdc41605ad5613b6ab7 (patch)
tree0fb79682fc8744ef2f2a0e326c48e2deb2f83186 /documentation
parent849b17bd15c53480b42dacedeb00fdfdf0854064 (diff)
Rename the secure and non-secure interrupts
Currently, the secure interrupts are named as FIQ and the non-secure interrupts are named as IRQ. In GICv3 mode, the FIQ and IRQ have different definitions. * Secure Group 0 interrupts: Handled by EL3 and triggered by FIQ when running at Secure EL0/1. * Secure Group 1 interrupts: Handled by optee_os and triggered by IRQ when running at Secure EL0/1. * Non-secure Group1 interrupts: Handled by the rich os and triggered by FIQ when running at Secure EL0/1. The "Secure Group 1" interrupts are the "native" interrupts handled by optee_os. They are same as the "secure" interrupts used in optee_os for now. But they are triggered by FIQ in GICv2 mode while by IRQ in GICv3 mode. The "Secure Group 0" and "Non-secure Group1" interrupts are the "foreign" interrupts that will cause the exiting of optee_os. (e.g. switch back to normal world) The "Non-secure Group1" interrupts are same as the "non-secure"interrupts used in optee_os for now. But they are triggered by IRQ in GICv2 mode while by FIQ in GICv3 mode. This patch renames these interrupts to the generic names - "Foreign interrupts" and "Native interrupts". For the support of GICv3 mode in the future, we can redefine the macros of "native interrupt" and "foreign interrupt" to IRQ and FIQ. Signed-off-by: David Wang <david.wang@arm.com> Reviewed-by: Joakim Bech <joakim.bech@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org> Tested-by: Etienne Carriere <etienne.carriere@linaro.org> (b2260)
Diffstat (limited to 'documentation')
-rw-r--r--documentation/interrupt_handling.md14
-rw-r--r--documentation/optee_design.md31
2 files changed, 31 insertions, 14 deletions
diff --git a/documentation/interrupt_handling.md b/documentation/interrupt_handling.md
index 7ca81217..80633579 100644
--- a/documentation/interrupt_handling.md
+++ b/documentation/interrupt_handling.md
@@ -19,8 +19,18 @@ The processor is configured to use:
* Monitor vector for SMC exceptions
* State vector for IRQ exceptions
-Interrupts handled by secure world are sent as FIQs and interrupts handled
-by normal world are sent as IRQs.
+Two types of interrupt are defined in optee_os:
+* Native interrupt - The interrupt handled by optee_os
+ (for example: secure interrupt)
+* Foreign interrupt - The interrupt not handled by optee_os
+ (for example: non-secure interrupt which is handled by normal world)
+
+For ARM GICv2 mode, native interrupt is sent as FIQ and foreign interrupt is
+sent as IRQ.
+
+For ARM GICv3 mode, foreign interrupt is sent as FIQ which could be handled
+by either secure world (EL3 in AArch64) or normal world. This mode is not
+supported yet.
Since IRQs are received using the state vector the actual vector used
depends on the current state of the CPU. If the NS (non-secure) bit in SCR
diff --git a/documentation/optee_design.md b/documentation/optee_design.md
index 073b46b5..cb0a5afa 100644
--- a/documentation/optee_design.md
+++ b/documentation/optee_design.md
@@ -151,12 +151,13 @@ table when the TA context is activated.
![Select xlation table](images/xlat_table.png "Select xlation table")
## Translation tables and switching to normal world
-When switching to normal world either via an IRQ or RPC there is a chance
-that secure world will resume execution on a different CPU. This means that
-the new CPU need to be configured with the context of the currently active
-TA. This is solved by always setting the TA context in the CPU when
-resuming execution. Here is room for improvements since it is more likely
-than not that it is the same CPU that resumes execution in secure world.
+When switching to normal world either via a foreign interrupt or RPC there
+is a chance that secure world will resume execution on a different CPU.
+This means that the new CPU need to be configured with the context of the
+currently active TA. This is solved by always setting the TA context in
+the CPU when resuming execution. Here is room for improvements since it is
+more likely than not that it is the same CPU that resumes execution in
+secure world.
# 6. Stacks
Different stacks are used during different stages. The stacks are:
@@ -216,11 +217,16 @@ is restored it will continue at the next instruction as if this function did a
normal return. CPU switches to use the temp stack before returning to normal
world.
-## IRQ exit
-IRQ exit occurs when OP-TEE receives an IRQ, which is always handled in normal
-world. IRQ exit is similar to RPC exit but it is `thread_irq_handler()` and
-`elx_irq()` (respectively for ARMv7-A/Aarch32 and for Aarch64) that saves the
-thread state instead. The thread is resumed in the same way though.
+## Foreign interrupt exit
+Foreign interrupt exit occurs when OP-TEE receives a foreign interrupt. For ARM
+GICv2 mode, foreign interrupt is sent as IRQ which is always handled in normal
+world. Foreign interrupt exit is similar to RPC exit but it is
+`thread_irq_handler()` and `elx_irq()` (respectively for ARMv7-A/Aarch32 and
+for Aarch64) that saves the thread state instead. The thread is resumed in the
+same way though.
+For ARM GICv3 mode, foreign interrupt is sent as FIQ which could be handled by
+either secure world (EL3 in AArch64) or normal world. This mode is not supported
+yet.
*Notes for ARMv7/AArch32:*
SP_IRQ is initialized to temp stack instead of a separate stack. Prior to
@@ -233,7 +239,8 @@ original `SP_EL0` is saved in the thread context to be restored when resuming.
## Resume entry
OP-TEE is entered using the temp stack in the same way as for normal entry. The
thread to resume is looked up and the state is restored to resume execution. The
-procedure to resume from an RPC exit or an IRQ exit is exactly the same.
+procedure to resume from an RPC exit or an foreign interrupt exit is exactly
+the same.
## Syscall
Syscalls are executed using the thread stack.