From: Sebastian Andrzej Siewior <[email protected]> Sent: Wednesday, March 18, 2026 3:11 AM > > On 2026-03-17 17:26:39 [+0000], Michael Kelley wrote: > > > > Who is other one and does it have its add_interrupt_randomness() there > > > > already? > > > > > > It's the arm64 path of the hv support. Regarding the vmbus IRQ, it seems > > > to be fully handled here, without an equivalent of > > > arch/x86/kernel/cpu/mshyperv.c. > > > > The arm64 path is the call to request_percpu_irq() in vmbus_bus_init(). > > That call is only made when running on arm64. See the code comment in > > vmbus_bus_init(). > > > > The specified interrupt handler is vmbus_percpu_isr(), which again runs > > only on arm64. It calls vmbus_isr(), which starts the common path for both > > x86/x64 and arm64. > > > > Then the slight weirdness is that the standard Linux IRQ handling for > > per-CPU IRQs on arm64 with a GICv3 (which is what Hyper-V emulates) > > does *not* call add_interrupt_randomness(). The function > > gic_irq_domain_map() sets the IRQ handler for PPI range to > > handle_percpu_devid_irq(), and that function does not do > > add_interrupt_randomness(). The other variant, handle_percpu_irq(), > > calls handle_irq_event_percpu(), which *does* do the > > add_interrupt_randomness(). > > So despite all the generic code on arm64 does not do it? Then don't > workaround this in your driver. Either talk to the IRQ maintainer and > suggest adding it there so everyone benefits from or don't because there > might be a reason to avoid it. Having it in driver code is wrong.
FWIW, I've researched the history of handle_percpu_devid_irq(). It dates back to 2011, which is probably when the ARM architecture first introduced per-CPU interrupts. At that time, it did not do add_interrupt_randomness(). An RFC patch set [1] in 2017 proposed adding the interrupt randomness as a side effect of other changes, but that patch set evidently did not move forward. There was no mailing list discussion of the interrupt randomness aspect of the patch set. I'll raise the topic with ARM maintainers and IRQ subsystem maintainers to see if there's any reason one way or the other. I would not be surprised if adding interrupt randomness is intentionally excluded because these per-CPU interrupts were historically used for IPIs and timers only. What's changed is that ARM64 is now used significantly in data centers, and support for VMs is super important. The per-CPU interrupts are now used for more that IPIs and timers, such as in the Hyper-V case, and handle_percpu_devid_irq() was never reconsidered in that light. I would expect a reluctance to burden the IPI and timer interrupt paths with the overhead of add_interrupt_randomness(). But the Hyper-V VMBus case still needs it because that's the primary source of interrupt entropy in the VM. There aren't necessarily other devices generating non-per-CPU interrupts like in a physical machine. To me, it is perfectly valid for the IPI & timer interrupt paths to want to skip interrupt randomness, while the Hyper-V VMBus interrupt path needs it, and we will be back where we are now. Related, *not* doing add_interrupt_randomness() on the ARM64 Hyper-V synthetic timer path is consistent with the ARM64 architectural timer, since it also uses handle_percpu_devid_irq(). I did the original work to get the Hyper-V synthetic timers working on ARM64 back in 2019 (?), but I don't recall if that consistency with the ARM64 architectural timer was intentional or accidental. Again, I'll raise this with the appropriate maintainers and see what the feedback is. Michael [1] https://lore.kernel.org/lkml/[email protected]/ > > > So at this point, putting the add_interrupt_randomness() in > > vmbus_isr() is needed to catch both architectures. If the lack of > > add_interrupt_randomness() in handle_percpu_devid_irq() is a bug, > > then that would be a cleaner way to handle this. But maybe there's > > a reason behind the current behavior of handle_percpu_devid_irq() > > that I'm unaware of. > > > > Michael > > Sebastian
