From: Naman Jain <[email protected]> Sent: Monday, August 17, 2026 8:31 AM > > 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. >
Thanks for getting the definitive answer. Having it be async was initially plausible to me given the experience we had with the VMBus MODIFYCHANNEL message. But upon further reflection, the VMBus case was really more because it is a messaging protocol instead of a "call". As a "call", the hypercall really should be synchronous. And that's consistent with the arm64 behavior of setting the GICD register. With this top-level question now resolved, I'll review the patch series at a more detailed level to see if anything else comes up, but it looks pretty good in my initial read-through. Michael
