I have been reviewing how OP‑TEE is implemented and how secure‑world invocations behave. The goal was to determine whether an OP‑TEE call can delay the Linux side and introduce latency depending on the time spent in the secure world.
Similar latency effects are already known for EFI runtime services, but this was not documented. To mitigate the impact, EFI runtime invocations can be restricted to specific CPUs so that real‑time workloads on other CPUs remain unaffected. This mechanism, however, is only described in the commit that introduced it.
This change adds a firmware section that documents these behaviours explicitly. It highlights cases where firmware can delay the kernel, information that may be unfamiliar to some users and surprising-or concerning-to others.
Assisted-by: Microsoft-Copilot Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de ---
I would appreciate an ACK from the OP-TEE camp that I got my little research right.
Documentation/core-api/real-time/hardware.rst | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+)
diff --git a/Documentation/core-api/real-time/hardware.rst b/Documentation/core-api/real-time/hardware.rst index 19f9bb3786e03..fb113848c2f70 100644 --- a/Documentation/core-api/real-time/hardware.rst +++ b/Documentation/core-api/real-time/hardware.rst @@ -130,3 +130,95 @@ https://github.com/Linutronix/RTC-Testbench. The goal of this project is to validate real-time network communication. It can be thought of as a "cyclictest" for networking and also serves as a starting point for application development. + +Firmware +-------- + +The firmware often plays a significant role in system operation because it can +perform tasks that the kernel cannot directly access, and in some cases it can +even preempt or intercept the kernel. + +A common example of firmware assisting the kernel is when it provides a generic +interface to a resource. Instead of accessing an RTC chip through an I2C host +controller, the kernel may query the firmware for the current time, and the +firmware then accesses the RTC behind the scenes. + +Firmware can also intercept kernel execution by providing services that +temporarily take control of the system. One example is memory scrubbing, where +the firmware periodically pauses the kernel, reads back portions of system +memory, and then returns control. During this time, the kernel is effectively +interrupted. +In contrast, some systems provide hardware‑based memory scrubbing, which +operates independently of firmware or software. See +Documentation/edac/scrub.rst for details. + +If the kernel is intercepted for longer periods then these periods can be made +visible with the hardware latency detector. See +Documentation/trace/hwlat_detector.rst. + +The kernel can also be intercepted in response to specific events, such as +overheating. In this case, the firmware may throttle the CPU or shut it down +immediately to prevent hardware damage. + +Unless the firmware is well documented, it should be thoroughly tested to +uncover any unexpected behaviour. + +EFI +~~~~ + +EFI provides runtime services that act as a communication interface between the +firmware and the operating system. One such service is reading and writing EFI +variables, which are used, for example, to determine the boot source. + +Invoking a runtime service may require the architecture to disable kernel +preemption or interrupts during the call. This means the duration of a service +invocation directly affects the system’s observable latency. There is also +nothing that prevents a service call from disabling interrupts internally while +it runs. + +For these reasons, EFI runtime services are disabled by default on a PREEMPT_RT +kernel. They can still be enabled at boot time or via a Kconfig option if +required. +The native EFI runtime service implementation (where both the EFI service and +the kernel are either 32‑bit or 64‑bit executables) uses a wrapper mechanism +that invokes the service through a dedicated workqueue. This workqueue is named +efi_runtime, and it can be restricted to a housekeeping CPU using the +``/sys/devices/virtual/workqueue/efi_runtime/cpumask`` sysfs file. Assigning it +to a housekeeping CPU ensures that potentially long service invocations do not +impact the real‑time workload which is restricted to other CPUs. + +It must also be verified that the runtime services behave as expected. Some +implementations on the x86 architecture pause all other CPUs while one CPU +performs the service call. In such cases, the interruption affects all CPUs, +and restricting the workqueue to a single CPU provides no benefit. + +OP-TEE (ARM) +~~~~~~~~~~~~ + +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. + +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. + +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. + +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. + +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.
++Cc Jens on his kernel.org email
On Wed, 1 Jul 2026 at 12:12, Sebastian Andrzej Siewior bigeasy@linutronix.de wrote:
I have been reviewing how OP‑TEE is implemented and how secure‑world invocations behave. The goal was to determine whether an OP‑TEE call can delay the Linux side and introduce latency depending on the time spent in the secure world.
Similar latency effects are already known for EFI runtime services, but this was not documented. To mitigate the impact, EFI runtime invocations can be restricted to specific CPUs so that real‑time workloads on other CPUs remain unaffected. This mechanism, however, is only described in the commit that introduced it.
This change adds a firmware section that documents these behaviours explicitly. It highlights cases where firmware can delay the kernel, information that may be unfamiliar to some users and surprising-or concerning-to others.
Assisted-by: Microsoft-Copilot Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de
I would appreciate an ACK from the OP-TEE camp that I got my little research right.
Documentation/core-api/real-time/hardware.rst | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+)
diff --git a/Documentation/core-api/real-time/hardware.rst b/Documentation/core-api/real-time/hardware.rst index 19f9bb3786e03..fb113848c2f70 100644 --- a/Documentation/core-api/real-time/hardware.rst +++ b/Documentation/core-api/real-time/hardware.rst @@ -130,3 +130,95 @@ https://github.com/Linutronix/RTC-Testbench. The goal of this project is to validate real-time network communication. It can be thought of as a "cyclictest" for networking and also serves as a starting point for application development.
+Firmware +--------
+The firmware often plays a significant role in system operation because it can +perform tasks that the kernel cannot directly access, and in some cases it can +even preempt or intercept the kernel.
+A common example of firmware assisting the kernel is when it provides a generic +interface to a resource. Instead of accessing an RTC chip through an I2C host +controller, the kernel may query the firmware for the current time, and the +firmware then accesses the RTC behind the scenes.
+Firmware can also intercept kernel execution by providing services that +temporarily take control of the system. One example is memory scrubbing, where +the firmware periodically pauses the kernel, reads back portions of system +memory, and then returns control. During this time, the kernel is effectively +interrupted. +In contrast, some systems provide hardware‑based memory scrubbing, which +operates independently of firmware or software. See +Documentation/edac/scrub.rst for details.
+If the kernel is intercepted for longer periods then these periods can be made +visible with the hardware latency detector. See +Documentation/trace/hwlat_detector.rst.
+The kernel can also be intercepted in response to specific events, such as +overheating. In this case, the firmware may throttle the CPU or shut it down +immediately to prevent hardware damage.
+Unless the firmware is well documented, it should be thoroughly tested to +uncover any unexpected behaviour.
+EFI +~~~~
+EFI provides runtime services that act as a communication interface between the +firmware and the operating system. One such service is reading and writing EFI +variables, which are used, for example, to determine the boot source.
+Invoking a runtime service may require the architecture to disable kernel +preemption or interrupts during the call. This means the duration of a service +invocation directly affects the system’s observable latency. There is also +nothing that prevents a service call from disabling interrupts internally while +it runs.
+For these reasons, EFI runtime services are disabled by default on a PREEMPT_RT +kernel. They can still be enabled at boot time or via a Kconfig option if +required. +The native EFI runtime service implementation (where both the EFI service and +the kernel are either 32‑bit or 64‑bit executables) uses a wrapper mechanism +that invokes the service through a dedicated workqueue. This workqueue is named +efi_runtime, and it can be restricted to a housekeeping CPU using the +``/sys/devices/virtual/workqueue/efi_runtime/cpumask`` sysfs file. Assigning it +to a housekeeping CPU ensures that potentially long service invocations do not +impact the real‑time workload which is restricted to other CPUs.
+It must also be verified that the runtime services behave as expected. Some +implementations on the x86 architecture pause all other CPUs while one CPU +performs the service call. In such cases, the interruption affects all CPUs, +and restricting the workqueue to a single CPU provides no benefit.
+OP-TEE (ARM) +~~~~~~~~~~~~
+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.
+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.
+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.
+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.
+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
Hi Sebastian!
I'll let Jens fill in the gaps. Some general comments below.
On Wed, 1 Jul 2026 at 12:12, Sebastian Andrzej Siewior bigeasy@linutronix.de wrote:
I have been reviewing how OP‑TEE is implemented and how secure‑world invocations behave. The goal was to determine whether an OP‑TEE call can delay the Linux side and introduce latency depending on the time spent in the secure world.
Similar latency effects are already known for EFI runtime services, but this was not documented. To mitigate the impact, EFI runtime invocations can be restricted to specific CPUs so that real‑time workloads on other CPUs remain unaffected. This mechanism, however, is only described in the commit that introduced it.
This change adds a firmware section that documents these behaviours explicitly. It highlights cases where firmware can delay the kernel, information that may be unfamiliar to some users and surprising-or concerning-to others.
Assisted-by: Microsoft-Copilot Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de
I would appreciate an ACK from the OP-TEE camp that I got my little research right.
Documentation/core-api/real-time/hardware.rst | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+)
diff --git a/Documentation/core-api/real-time/hardware.rst b/Documentation/core-api/real-time/hardware.rst index 19f9bb3786e03..fb113848c2f70 100644 --- a/Documentation/core-api/real-time/hardware.rst +++ 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
+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.
+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.
+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.
Cheers /Ilias
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?
+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)?
+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"?
+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.
Cheers /Ilias
Sebastian
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
On 2026-07-10 10:53:16 [+0300], Ilias Apalodimas wrote:
+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
So what I got so far: - linux has access to the normal world (not secure group 1) - OP-TEE has access to the secure world (secure group 1) This is for routing. And only secure world can manage secure and non-secure its non-secure. https://developer.arm.com/documentation/198123/0302/Configuring-the-Arm-GIC
But then we have ICC_PMR_EL1 to enable/ disable interrupts based on the priority and non-secure has limited priority range while secure has a wider range. It can disable non-secure interrupts. And it took me a while to get the right document and find this section: | The GIC security model provides Secure and Non-secure accesses to the | interrupt priority settings.The Non-secure accesses can configure | interrupts only in the lower priority half of the supported priority | values. Therefore, if the GIC implements 32 priority values, Non-secure | accesses see only 16 priority values.
Good. Let me update so it matches the reality more closely…
Sebastian
op-tee@lists.trustedfirmware.org
-
Ilias Apalodimas -
Jens Wiklander -
Sebastian Andrzej Siewior