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