0

Question

I need to hook a hardware interrupts as soon as possible, avoiding if possible any:

  • Other interruptions to take advantage of the CPU before mine.
  • The latency added by Linux kernel to schedule, stats, and propagate IRQs.

This question shows how to hook interrupts directly from the hardware interrupt, but according to this other question, it is specific to I64 and X86 architecture. For ARM, one single interrupt handler exists, and there is little information on how to hook this interrupt.

My question is:

How to hook ARM hardware interrupt directly under Linux?

Context

Working on an embedded Linux device based on ARM Cortex 7, I am trying to achieve hard real-time and low-latency response.

In that attempt, I made several changes that already improved significantly the jitter, latency and overall real-time performance:

  • A Preempt-RT patch is applied to the Linux Kernel.
  • The real-time software is integrated as an IRQ in a kernel module.
  • I disabled any non-critical driver and Linux service.
  • From the two cores, core 0 is isolated: it is dedicated to this IRQ only. (Actually, this is only partially done: some kernel threads related to IRQs are still running on core 0).

I checked that:

  • The processor frequency is not adjusted, energy governors are disabled by the preempt-rt patch.
  • Linux seems to have no way to increase the priority of IRQs
  • request_irq seems the deepest (closest to the hardware) IRQ that Linux provides.

After, this, I have some 35us response time average, with <5us typical deviation. However I still registered a couple of >500us response time when testing the system over several hours with load.

A hard real-time below 100us would be acceptable, but those 500us are out of range.

About FIQ:
Thanks to @Artlessnoise for it comments:
FIQ is another approach to the hard-real time on ARM, and I am exploring this other alternative separately. FIQ provides a first-priority interruption, that can preempt a standard IRQ. However, FIQ has some negative sides that make standard IRQ worth to explore:

  • The Linux that I am using (OpenSt-linux) uses the FIQ for Trustzone (Optee) mode.
  • FIQ uses GPLv2 license without Tovald note, making any driver using the Linux API to registers a FIQ GPLv2.
  • FIQ uses special registers, this either enforce the use of Assembler, or compiler-specific code (e.g. GCC manages FIQ code).

For all those reasons, I am not discarding the option of FIQ, but I am still interested in achieving and see the performance of an IRQs hook.

Adrian Maire
  • 14,354
  • 9
  • 45
  • 85
  • I am attempting to replace the IVT and also to replace IRQs by FIQs – Adrian Maire Apr 24 '23 at 13:24
  • There is a kernel header to hook the fiq and it allows multiple callers. Hooking the IRQ doesn't make any sense on an ARM cpu. Even if you can, you are going to get lower latency with the FIQ. See for instance, [fiq.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/include/asm/fiq.h). Also, your question is more [tag:linux-kernel] than [tag:linux]? You didn't expect to do this in user mode, did you? – artless noise May 27 '23 at 20:50
  • Actually, I am **also** looking how to implement properly FIQ (you can see my other question about FIQ and yocto). Regarding this question, I managed to get some results by manually handling the GIC module, still WIP. – Adrian Maire May 27 '23 at 21:39
  • While, you certainly can try to hook the main vector, the FIQ is a better route. It is supported by the architecture and is meant for 'Soft DMA' tasks. Moreover, the Linux kernel already has mechanics to claim and release a FIQ, so it maybe possible to use a module with distribution kernels, etc. At the very least you have a easier time merging upstream changes if you go with the FIQ. Replacing the IRQ is possible, but unless you are writing a rootkit, or some IRQ monitoring function, it makes little sense, compared to the FIQ. FIQ == **achieve hard real-time and low-latency response** . – artless noise May 30 '23 at 14:41
  • I closed the question as this is a technically a bad route to go for almost all use cases. There are only a select few instances where you actually want to hook the IRQ. So, I feel a direct answer to this question is harmful as people may be ignorant of the FIQ and believe that hooking the IRQ is the best option, given code to do it. I am looking at you ChatGPT. – artless noise May 30 '23 at 14:44
  • Since when do we refuse a question for "ChatGPT" convenience? A simple disclaim "FIQ might work better for you" would work. By the way, I am still interested in an answer to this question. FIQ is giving me many troubles (because it's used as a gate for OPTEE mode (secure mode)). @artlessnoise, please, don't close question because you don't like it, or because there is another way that seems better to you. – Adrian Maire May 30 '23 at 15:56
  • The ChatGPT was a joke. You are correct that TrustZone double use FIQ. But that is also germain to the question and not mentioned. You will have some issue with the GIC when you run in the 'normal world'. There are some limited features available to Linux if you have a secure world. It is not that I don't like your question. It is that you posit for a normal ARM that the x86 method of doing things should translate. This is wrong. – artless noise May 30 '23 at 20:50
  • Please add information (especially to the title) that Linux is running under a secure supervisor. – artless noise May 30 '23 at 20:57

0 Answers0