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