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

[Naman Jain <namjain@linux.microsoft.com>]

On 8/17/2026 5:45 PM, Naman Jain wrote:
> 
> 
> On 8/17/2026 9:08 AM, Michael Kelley wrote:
>> From: Naman Jain <namjain@linux.microsoft.com> 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
>