Question: interrupt randomness and handle_percpu_devid_irq()

[Michael Kelley]

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().

Thoughts?

Michael