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

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

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Sebastian Siewior wrote:
"This is feeding entropy and would like to see interrupt registers. But
since this is invoked from a thread it won't."

So move it back to where it is always in interrupt context.

Fixes: f8e6343b7a89 ("Drivers: hv: vmbus: Simplify allocation of vmbus_evt")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 drivers/hv/vmbus_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bc4fc1951ae1..28025a264861 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1361,8 +1361,6 @@ static void __vmbus_isr(void)
 
 	vmbus_message_sched(hv_cpu, hv_cpu->hyp_synic_message_page);
 	vmbus_message_sched(hv_cpu, hv_cpu->para_synic_message_page);
-
-	add_interrupt_randomness(vmbus_interrupt);
 }
 
 static DEFINE_PER_CPU(bool, vmbus_irq_pending);
@@ -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");
 
-- 
2.47.3

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

[Sebastian Andrzej Siewior]

On 2026-03-17 09:09:27 [+0100], Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Sebastian Siewior wrote:
> "This is feeding entropy and would like to see interrupt registers. But
> since this is invoked from a thread it won't."
> 
> So move it back to where it is always in interrupt context.
> 
> Fixes: f8e6343b7a89 ("Drivers: hv: vmbus: Simplify allocation of vmbus_evt")
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  drivers/hv/vmbus_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index bc4fc1951ae1..28025a264861 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1361,8 +1361,6 @@ static void __vmbus_isr(void)
>  
>  	vmbus_message_sched(hv_cpu, hv_cpu->hyp_synic_message_page);
>  	vmbus_message_sched(hv_cpu, hv_cpu->para_synic_message_page);
> -
> -	add_interrupt_randomness(vmbus_interrupt);
>  }
>  
>  static DEFINE_PER_CPU(bool, vmbus_irq_pending);
> @@ -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()?

Sebastian

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

[Jan Kiszka]

On 17.03.26 12:05, Sebastian Andrzej Siewior wrote:
> On 2026-03-17 09:09:27 [+0100], Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Sebastian Siewior wrote:
>> "This is feeding entropy and would like to see interrupt registers. But
>> since this is invoked from a thread it won't."
>>
>> So move it back to where it is always in interrupt context.
>>
>> Fixes: f8e6343b7a89 ("Drivers: hv: vmbus: Simplify allocation of vmbus_evt")
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>  drivers/hv/vmbus_drv.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
>> index bc4fc1951ae1..28025a264861 100644
>> --- a/drivers/hv/vmbus_drv.c
>> +++ b/drivers/hv/vmbus_drv.c
>> @@ -1361,8 +1361,6 @@ static void __vmbus_isr(void)
>>  
>>  	vmbus_message_sched(hv_cpu, hv_cpu->hyp_synic_message_page);
>>  	vmbus_message_sched(hv_cpu, hv_cpu->para_synic_message_page);
>> -
>> -	add_interrupt_randomness(vmbus_interrupt);
>>  }
>>  
>>  static DEFINE_PER_CPU(bool, vmbus_irq_pending);
>> @@ -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.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

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

[Sebastian Andrzej Siewior]

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?
This is a driver, this does not belong here.

> Jan

Sebastian

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

[Jan Kiszka]

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.

> 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

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

[Michael Kelley]

From: Jan Kiszka <jan.kiszka@siemens.com> 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

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

[Sebastian Andrzej Siewior]

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

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

[Michael Kelley]

From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Sent: Wednesday, March 18, 2026 3:11 AM
> 
> 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.

FWIW, I've researched the history of handle_percpu_devid_irq(). It dates
back to 2011, which is probably when the ARM architecture first introduced
per-CPU interrupts. At that time, it did not do add_interrupt_randomness().
An RFC patch set [1] in 2017 proposed adding the interrupt randomness
as a side effect of other changes, but that patch set evidently did not
move forward. There was no mailing list discussion of the interrupt
randomness aspect of the patch set.

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

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.

Michael

[1] https://lore.kernel.org/lkml/20170907232542.20589-3-paul.burton@imgtec.com/


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

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

[Sebastian Andrzej Siewior]

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

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

[Michael Kelley]

From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> 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