On Fri, 10 Jul 2026 at 10:31, Sebastian Andrzej Siewior bigeasy@linutronix.de wrote:
On 2026-07-10 09:29:55 [+0300], Ilias Apalodimas wrote:
Hi Sebastian!
Hi Ilias,
+++ b/Documentation/core-api/real-time/hardware.rst @@ -130,3 +130,95 @@ https://github.com/Linutronix/RTC-Testbench.
[...]
+OP-TEE (ARM) +~~~~~~~~~~~~
That's RISC-V as well nowadays
I did not find much here. Their architecture isn't the same as on ARM is it? But the overall concept is the same, right?
I haven't checked the IRQ vectors on risc-v, but I assume they have a similar logic since that's an OP-TEE design decision not a per architecture one.
+OP‑TEE uses a global serialization mechanism (the "big lock"), ensuring that on +each core only one OP‑TEE thread executes secure‑world code at a time.
+Execution flows from the normal world (Linux) into the secure world (OP‑TEE) +through the secure monitor at EL3. Linux and OP‑TEE cannot disable or mask each +other’s interrupts because both run at EL1 in different security states.
That's not always true. It depends on a combination of OP-TEE and TF-A configs iirc. The most common though is that IRQs and FIQs are directly delivered to S-EL1, in which case OP-TEE can mask IRQs. There's also a difference between GICv2 and GICv3 in the way interrupts are delivered.
You are saying that OP-TEE can mask Linux' interrupts or if OP-TEE instructs TF-A to do so (via config)?
OP-TEE can mask Linux IRQs
+Architecturally, the secure monitor can mask or reroute normal‑world interrupts +before entering the secure world. In a correct OP‑TEE/ TF‑A implementation, it +does not do this for the duration of secure calls. Normal‑world interrupts +remain deliverable, and a normal‑world IRQ will preempt OP‑TEE via EL3 and +return control to Linux.
The 'sane' case is indeed where IRQs are delivered to OP-TEE which exits back to Linux immediately.
+Secure‑world interrupts (FIQs) are possible if the SoC routes a device's +interrupt as secure. Such a secure FIQ will preempt Linux immediately, trap +into EL3, and transfer control to OP‑TEE's secure interrupt handler. Linux +cannot mask or preempt this. Secure FIQ handlers must therefore be extremely +short to avoid introducing noticeable latency.
There are also 'fast SMCs', which run with IRQs disabled for their entire duration.
can their be distinguished somehow from normal SMC invocations or is just a consequence that the secure monitor does not enable interrupts during transition for some of the "functions"?
They can be identified. There's a function identifier defined in the SMC calling conventions doc [0]. Bit 31 is always 1 for fast calls and 0 for yielding.
+The transition from normal world -> secure monitor -> OP‑TEE and back introduces +additional latency due to world switching and context save/ restore. This +overhead is typically a few microseconds and usually remains in the noise +floor.
That's correct.
+If the secure monitor masks normal‑world interrupts during OP‑TEE invocations, +or if OP‑TEE uses long‑running secure FIQ handlers, then OP‑TEE can introduce
+measurable latency spikes.
2.53.0
Overall I think this is worth documenting, but infortunately there's a wider range of configs and corner cases we have to describe.
Okay.
[0] https://developer.arm.com/documentation/den0028/h/?lang=en
Cheers /Ilias
Cheers /Ilias
Sebastian
Hi,
On Fri, Jul 10, 2026 at 9:53 AM Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Fri, 10 Jul 2026 at 10:31, Sebastian Andrzej Siewior bigeasy@linutronix.de wrote:
On 2026-07-10 09:29:55 [+0300], Ilias Apalodimas wrote:
Hi Sebastian!
Hi Ilias,
+++ b/Documentation/core-api/real-time/hardware.rst @@ -130,3 +130,95 @@ https://github.com/Linutronix/RTC-Testbench.
[...]
+OP-TEE (ARM) +~~~~~~~~~~~~
That's RISC-V as well nowadays
I did not find much here. Their architecture isn't the same as on ARM is it? But the overall concept is the same, right?
I haven't checked the IRQ vectors on risc-v, but I assume they have a similar logic since that's an OP-TEE design decision not a per architecture one.
+OP‑TEE uses a global serialization mechanism (the "big lock"), ensuring that on +each core only one OP‑TEE thread executes secure‑world code at a time.
+Execution flows from the normal world (Linux) into the secure world (OP‑TEE) +through the secure monitor at EL3. Linux and OP‑TEE cannot disable or mask each +other’s interrupts because both run at EL1 in different security states.
That's not always true. It depends on a combination of OP-TEE and TF-A configs iirc. The most common though is that IRQs and FIQs are directly delivered to S-EL1, in which case OP-TEE can mask IRQs. There's also a difference between GICv2 and GICv3 in the way interrupts are delivered.
You are saying that OP-TEE can mask Linux' interrupts or if OP-TEE instructs TF-A to do so (via config)?
OP-TEE can mask Linux IRQs
You can find more about interrupts in OP-TEE here https://optee.readthedocs.io/en/latest/architecture/core.html#interrupt-hand...
+Architecturally, the secure monitor can mask or reroute normal‑world interrupts +before entering the secure world. In a correct OP‑TEE/ TF‑A implementation, it +does not do this for the duration of secure calls. Normal‑world interrupts +remain deliverable, and a normal‑world IRQ will preempt OP‑TEE via EL3 and +return control to Linux.
The 'sane' case is indeed where IRQs are delivered to OP-TEE which exits back to Linux immediately.
+Secure‑world interrupts (FIQs) are possible if the SoC routes a device's +interrupt as secure. Such a secure FIQ will preempt Linux immediately, trap +into EL3, and transfer control to OP‑TEE's secure interrupt handler. Linux +cannot mask or preempt this. Secure FIQ handlers must therefore be extremely +short to avoid introducing noticeable latency.
There are also 'fast SMCs', which run with IRQs disabled for their entire duration.
can their be distinguished somehow from normal SMC invocations or is just a consequence that the secure monitor does not enable interrupts during transition for some of the "functions"?
They can be identified. There's a function identifier defined in the SMC calling conventions doc [0]. Bit 31 is always 1 for fast calls and 0 for yielding.
This is a calling convention and is not controlled by hardware. There are exceptions for the FF-A SMCs, for instance.
Cheers, Jens
+The transition from normal world -> secure monitor -> OP‑TEE and back introduces +additional latency due to world switching and context save/ restore. This +overhead is typically a few microseconds and usually remains in the noise +floor.
That's correct.
+If the secure monitor masks normal‑world interrupts during OP‑TEE invocations, +or if OP‑TEE uses long‑running secure FIQ handlers, then OP‑TEE can introduce
+measurable latency spikes.
2.53.0
Overall I think this is worth documenting, but infortunately there's a wider range of configs and corner cases we have to describe.
Okay.
[0] https://developer.arm.com/documentation/den0028/h/?lang=en
Cheers /Ilias
Cheers /Ilias
Sebastian
op-tee@lists.trustedfirmware.org
-
Ilias Apalodimas -
Jens Wiklander