Zephyr: zero-latency IRQ behavior is not documented?

[pabigot]

ARM zero-latency IRQ functionality was added some time this year, but there appears to be no documentation on what it does and its interaction with other thread and interrupt behavior.

From what I can tell, zero-latency IRQs will be taken even when interrupts are disabled, and there is a hint that meta-irq priority threads in the future may be given control from a zero-latency IRQ.

It would help if the behavior of this feature were documented, and suggestions provided about how to mitigate latency induced as a result of such an interrupt, and perhaps restrictions on what is permitted within a ZLI handler to prevent breaking otherwise working code due to broken locks.

[aescolar]

Triaging as low: This would seem borderline and enhancement

[aescolar]

CC: @ioannisg

[nashif]

config ZERO_LATENCY_IRQS
        bool "Enable zero-latency interrupts"
        depends on CPU_CORTEX_M_HAS_BASEPRI
        help
          The kernel may reserve some of the highest interrupts priorities in
          the system for its own use. These interrupts will not be masked
          by interrupt locking.
          When connecting interrupts the kernel will offset all interrupts
          to lower priority than those reserved by the kernel.
          Zero-latency interrupt can be used to set up an interrupt at the
          highest interrupt priority which will not be blocked by interrupt
          locking.
          Since Zero-latency ISRs will run in the same priority or possibly at
          higher priority than the rest of the kernel they cannot use any
          kernel functionality.

Maybe should be extracted and expanded on in https://docs.zephyrproject.org/latest/reference/kernel/other/interrupts.html

[pabigot]

As I learn more about this feature I think the documentation needs to expand on this:

...cannot use any kernel functionality.

Somebody might read that and think it's not really different from other ISRs, where you can do things like k_sem_give().

If that's not true, it should be explicitly mentioned.

If non-sleeping kernel API calls that reschedule are permitted in ZLI handlers there seems to be a problem because ZLIs will break spinlocks on non-SMP builds. If somebody's also using meta-irq threads to process the bottom half of the interrupt, that lock may be broken for a very long time.

ZLIs are extremely powerful and correspondingly dangerous. I don't really think clearly describing how they may be used should be a low priority, so I'm going to bump it. @aescolar if you disagree let's discuss next triage. I do think this might be converted to an enhancement, if that wasn't treated as a signal that it can be ignored. We don't seem to have a clear category for "feature works but only the people who implemented it are likely to be able to use it correctly".

[aescolar]

I do think this might be converted to an enhancement, if that wasn't treated as a signal that it can be ignored.

@pabigot I'd say this is an enhancement. But indeed how to motivate people to work on fixing/improving any area can be tricky. Something being an enhancement certainly does not mean it should be ignored.

[sslupsky]

I'll jump in here and ask that this be given some attention soon. I've been debugging some driver issues with the i2c_sam0 driver and I would like to understand this topic.