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

Hi,

On Fri, Jul 10, 2026 at 9:53=E2=80=AFAM Ilias Apalodimas
<[email protected]> wrote:
>
> 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 i=
s
> > 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=E2=80=91TEE uses a global serialization mechanism (the "big loc=
k"), ensuring that on
> > > > +each core only one OP=E2=80=91TEE thread executes secure=E2=80=91w=
orld code at a time.
> > > > +
> > > > +Execution flows from the normal world (Linux) into the secure worl=
d (OP=E2=80=91TEE)
> > > > +through the secure monitor at EL3. Linux and OP=E2=80=91TEE cannot=
 disable or mask each
> > > > +other=E2=80=99s interrupts because both run at EL1 in different se=
curity 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 t=
o
> > > 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-han=
dling

>
> >
> > > > +
> > > > +Architecturally, the secure monitor can mask or reroute normal=E2=
=80=91world interrupts
> > > > +before entering the secure world. In a correct OP=E2=80=91TEE/ TF=
=E2=80=91A implementation, it
> > > > +does not do this for the duration of secure calls. Normal=E2=80=91=
world interrupts
> > > > +remain deliverable, and a normal=E2=80=91world IRQ will preempt OP=
=E2=80=91TEE 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=E2=80=91world interrupts (FIQs) are possible if the SoC rou=
tes a device's
> > > > +interrupt as secure. Such a secure FIQ will preempt Linux immediat=
ely, trap
> > > > +into EL3, and transfer control to OP=E2=80=91TEE's secure interrup=
t 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=E2=80=91T=
EE and back introduces
> > > > +additional latency due to world switching and context save/ restor=
e. This
> > > > +overhead is typically a few microseconds and usually remains in th=
e noise
> > > > +floor.
> > >
> > > That's correct.
> > >
> > > > +
> > > > +If the secure monitor masks normal=E2=80=91world interrupts during=
 OP=E2=80=91TEE invocations,
> > > > +or if OP=E2=80=91TEE uses long=E2=80=91running secure FIQ handlers=
, then OP=E2=80=91TEE 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=3Den
>
> Cheers
> /Ilias
> >
> > > Cheers
> > > /Ilias
> >
> > Sebastian