On 8/17/2026 5:45 PM, Naman Jain wrote:
On 8/17/2026 9:08 AM, Michael Kelley wrote:
From: Naman Jain <[email protected]> Sent: Monday, August
10, 2026 2:07 AM
The Hyper-V vPCI MSI irqchip never installs an irq_retrigger() callback.
On CPU hot-unplug fixup_irqs() migrates the interrupts which are
affine to
the outgoing CPU to a new target. If an interrupt still has its
pending bit
set in the outgoing CPU's IRR at that point, fixup_irqs() resends it
on the
new target through the irqchip's irq_retrigger() callback. As the
Hyper-V
PCI/MSI chip does not provide that callback, the pending interrupt is
silently dropped, which can result in lost interrupts, stalls and "No
irq
handler for vector" messages during CPU hotplug.
Install irq_chip_retrigger_hierarchy() as the irq_retrigger()
callback for
the Hyper-V PCI/MSI irqchip, so that a pending interrupt is resent on
its
new target CPU via the parent x86 vector domain.
The RFC version of this patch set listed the asynchronous nature
of the HVCALL_RETARGET_INTERRUPT hypercall as a cause of the
problem. Is that hypercall still believed to be asynchronous?
My understanding of "asynchronous" would be that Hyper-V
does not guarantee that the retargeting of the interrupt to a new
vCPU has occurred when the hypercall returns. There is an
unspecified time period during which the interrupt could still be
directed to the vCPU that is going offline. Furthermore, Hyper-V
provides no rendezvous mechanism for the guest to know when
the interrupt is guaranteed to go to the new vCPU.
If the async behavior is indeed present, isn't it a problem, even
after this patch? irq_migrate_all_off_this_cpu() causes the
RETARGET_INTERRUPT hypercall to be made, but a new interrupt
could still be generated to the going-offline vCPU after fixup_irqs()
runs its loop searching for any pending interrupts. A new such
interrupt would be lost. The 1 millisecond delay in fixup_irqs()
probably mitigates this problem by giving Hyper-V time to complete
the retargeting. But it's not a 100% solution.
> > Assuming my thinking is correct, there isn't a 100% solution. But
the problem's existence, and the likely benefit of the 1 ms delay,
should be called out in the commit message and/or code
comments for future readers.
Please allow me to confirm with the Hyper-V team internally once. I may
have assumed asynchronous behavior because of the pending interrupt
after retarget. It could simply have been committed to the old route
before the retarget operation.
This is actually synchronous. So the fix in this series should suffice.
Sorry for the confusion.
I don't see any mentions of asynchronous behavior of that hypercall
anywhere in these 3 patches, so I think we should be good.
Regards,
Naman
I also wondered about arm64 where Hyper-V provides an
emulated GICv3. The RETARGET_INTERRUPT hypercall is not
used since the retargeting is done by writing to a GICD register.
Presumably on real GICv3 hardware, after the write the new
CPU is guaranteed to receive any subsequent interrupts. And if
an interrupt was pending at the time of the write, the appropriate
trigger happens in the new CPU, so everything works. As long
as Hyper-V is doing the emulation the same way (i.e., fully
synchronously), the problem would not occur on arm64
guests.
I'm reminded that a similar problem occurred with changing
the target CPU for a VMBus channel interrupt. The initial
Hyper-V implementation of the VMBus MODIFYCHANNEL
message was asynchronous, which caused the same problem
as seen here if a vCPU were to be taken offline. A later version
of the VMBus protocol added a notification that the change to
the target vCPU is complete, which solves the problem. See
vmbus_channel_set_cpu() and vmbus_send_modifychannel()
and the associated code comments.
Thanks for sharing this info. I'll check and get back.
Regards,
Naman
