From: Sebastian Andrzej Siewior <[email protected]> Sent: Thursday, March 19, 2026 2:57 AM > > On 2026-03-19 03:39:12 [+0000], Michael Kelley wrote: > > 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 > > Thank you. > > > 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. > > But if that is your concern, don't you have or should have something > similar to virtio-rng where you can feed high quality random data to the > guest?
Hyper-V provides a modest pool of entropy at VM boot time, in the form of a vendor-specific ACPI table. It is consumed by the guest in the function ms_hyperv_late_init() for the purpose of seeding the Linux random number generator, and works on both x86/x64 and arm64. But this is a one-shot operation at boot time. Hyper-V does not provide guests with an ongoing source of entropy like virtio-rng, so the guest must generate its own. And if the guest does a kexec(), the new kernel doesn't even get to start with that ACPI table entropy. Michael > > > 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. > > Again, thank you. > > > Michael > > Sebastian
