Re: RE: RE: [PATCH] Drivers: hv: vmbus: Move add_interrupt_randomness back to real interrupt

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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