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

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.
>=20
> [...]
>=20
> > +
> > +OP-TEE (ARM)
> > +~~~~~~~~~~~~
>=20
> 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?

> > +
> > +OP=E2=80=91TEE uses a global serialization mechanism (the "big lock"),=
 ensuring that on
> > +each core only one OP=E2=80=91TEE thread executes secure=E2=80=91world=
 code at a time.
> > +
> > +Execution flows from the normal world (Linux) into the secure world (O=
P=E2=80=91TEE)
> > +through the secure monitor at EL3. Linux and OP=E2=80=91TEE cannot dis=
able or mask each
> > +other=E2=80=99s interrupts because both run at EL1 in different securi=
ty states.
>=20
> 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)?

> > +
> > +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=91worl=
d interrupts
> > +remain deliverable, and a normal=E2=80=91world IRQ will preempt OP=E2=
=80=91TEE via EL3 and
> > +return control to Linux.
>=20
> The 'sane' case is indeed where IRQs are delivered to OP-TEE which
> exits back to Linux immediately.
>=20
> > +
> > +Secure=E2=80=91world 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=E2=80=91TEE's secure interrupt ha=
ndler. Linux
> > +cannot mask or preempt this. Secure FIQ handlers must therefore be ext=
remely
> > +short to avoid introducing noticeable latency.
>=20
> 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"?

> > +
> > +The transition from normal world -> secure monitor -> OP=E2=80=91TEE a=
nd back introduces
> > +additional latency due to world switching and context save/ restore. T=
his
> > +overhead is typically a few microseconds and usually remains in the no=
ise
> > +floor.
>=20
> That's correct.
>=20
> > +
> > +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, th=
en OP=E2=80=91TEE can introduce
> > +measurable latency spikes.
> > --
> > 2.53.0
> >
>=20
> Overall I think this is worth documenting, but infortunately there's a
> wider range of configs and corner cases we have to describe.

Okay.

> Cheers
> /Ilias

Sebastian