Re: Question: interrupt randomness and handle_percpu_devid_irq()

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-03-20 16:10:37 [+0100], Thomas Gleixner wrote:
> 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.

So we could wire up the generic/ arch code here and feed the
"randomness" from there and it from the driver bits.

> Thanks,
> 
>         tglx

Sebastian