Re: [PATCH] Documentation: Extend the real-time hardware bits with some firmware bits

On Fri, 10 Jul 2026 at 10:31, Sebastian Andrzej Siewior
<[email protected]> 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