Re: Question about interrupt prioriyt of ARM GICv3/4

[Marc Zyngier]

On Fri, 06 Dec 2024 08:33:11 +0000,
richard clark <richard.xnu.clark@xxxxxxxxx> wrote:
> 
> Hi,
> Currently seems the GICv3/4 irqchip configures all the interrupts as
> the same priority, I am thinking about to minimize the latency of the
> interrupt for a particular device, e.g, the arm arch_timer in the RTL
> system. The question is,
> 1. Why don't we provide a /proc or /sys interface for the enduser to
> set the priority of a specific interrupt(SPI/PPI)?

I'm afraid this really has nothing to do with any particular interrupt
architecture.

Before thinking of exposing the interrupt priority to userspace, you
should look at what this translates into for the kernel once you allow
interrupts to be preempted by another one with a higher priority.

This means that at every point where you would normally see a
local_irq_save(), spinlock_irqsave() or equivalent, you would need to
explicitly specify the priority that you allow for preemption. You
should then make sure that any code that can be run during an
interrupt is reentrant. You need to define which data structures can
be manipulated at which priority level... The list goes on.

If you want a small taste of the complexity, just look at what
handling NMIs (or even pseudo-NMIs in the case of GICv3) means, and
generalise it to not just two, but an arbitrary range of priorities.

If you want the full blown experience, look at the BSDs and their use
of spl*(). I don't think anyone has any plan to get there, and the RT
patches have shown that there is little need for it.

> 2. Is there any way to verify the higher priority interrupt will have
> more dominant to be selected to the CPU (IOW, the priority is really
> working) in case of multiple different interrupts asserted to the GIC
> at the same time(some debug registers of GIC like GICD_REEMPT_CNT :-)
> to record higher priority wins)?

The GIC architecture makes no promise that the interrupt you
acknowledge is the highest priority pending interrupt, because this is
by definition a very racy process.

Also, even on busy systems, you will very rarely see two interrupts
targeting the same CPU being made pending at the same time, so that
the interrupt delivery system would have to arbitrate between the two.
That's because interrupts are vanishingly rare in the grand scheme of
things.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.