Re: Question: interrupt randomness and handle_percpu_devid_irq()

[Thomas Gleixner <tglx@kernel.org>]

On Thu, Mar 19 2026 at 19:34, Michael Kelley wrote:
> The function header comment for handle_percpu_devid_irq() says that it is the
> same as handle_percpu_irq(), but with the addition of a pointer to a percpu
> variable with the real device id. That makes sense. But there's another difference:
> handle_percpu_irq() calls add_interrupt_randomness() [via handle_irq_event_percpu()],
> while handle_percpu_devid_irq() does not.
>
> Question: Is there a reason for this difference in handling interrupt randomness?
> Or is it just an oversight? handle_percpu_devid_irq() is used, for example, for the
> SGIs and PPIs on the GICv3 chip, so I wondered if IPIs (as built on SGIs) & PPIs
> specifically did not want the overhead of add_interrupt_randomness(). But then
> GICv5 is doing IPIs using LPIs, which use handle_percpu_irq() and hence *do*
> add interrupt randomness. That seemed inconsistent, which didn't help provide
> an answer.
>
> The question arises in the context of Linux guests running on Hyper-V. Hyper-V
> VMBus interrupts to the guest are per-CPU interrupts in Linux, using a PPI on
> arm64. So these interrupts do not call add_interrupt_randomness(), which is a
> problem because these guests don't have much other way to get entropy. To
> fix this, the VMBus ISR has always had an explicit call to
> add_interrupt_randomness(). But maybe that's not the best approach, and
> handle_percpu_devid_irq() should be fixed to call add_interrupt_randomness().

I don't think there is a real good reason unless any of those interrupts
is NMI like.

Thanks,

        tglx