From: Jan Kiszka <[email protected]> Sent: Tuesday, March 17, 2026 6:34 AM > > On 17.03.26 14:22, Sebastian Andrzej Siewior wrote: > > On 2026-03-17 12:56:02 [+0100], Jan Kiszka wrote: > >>>> @@ -1410,6 +1408,8 @@ void vmbus_isr(void) > >>>> lockdep_hardirq_threaded(); > >>>> __vmbus_isr(); > >>>> } > >>>> + > >>>> + add_interrupt_randomness(vmbus_interrupt); > >>>> } > >>>> EXPORT_SYMBOL_FOR_MODULES(vmbus_isr, "mshv_vtl"); > >>> > >>> Why not sysvec_hyperv_callback()? > >> > >> Because we do not want to be x86-only. > > > > 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 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 > > > This is a driver, this does not belong here. > > Don't argue with me, I didn't put it here in the beginning. Maybe > Michael can shed more light on this (and sorry for having forgotten to > CC you on this patch). > > Jan > > -- > Siemens AG, Foundational Technologies > Linux Expert Center
