Re: [PATCH v2 1/3] PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip

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.

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