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

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

On 8/24/2026 10:29 PM, Wei Liu wrote:
> On Mon, Aug 24, 2026 at 11:57:56AM +0530, Naman Jain wrote:
>>
>>
>> On 8/24/2026 5:44 AM, Wei Liu wrote:
>>> On Thu, Jul 30, 2026 at 04:56:27PM +0530, Naman Jain wrote:
>>>>
>>>>
>>>> On 7/28/2026 7:34 PM, sashiko-bot@kernel.org wrote:
>>>>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>>>>>
>>>>> Pre-existing issues:
>>>>> - [High] The fix for dropped pending interrupts during CPU hot-unplug was missed in the sister Hyper-V root partition MSI domain.
>>>>> --
>>>>>
>>>>> --- Patch [1]: [PATCH 1/3] PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip ---
>>>>> commit b8b1c843c457dd145f0d360b44f4b1bf34bd8cf5
>>>>> Author: Naman Jain <namjain@linux.microsoft.com>
>>>>>
>>>>> PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip
>>>>>
>>>>> 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. 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.
>>>>>
>>>>> Fixes: 4daace0d8ce85 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
>>>>> Cc: stable@vger.kernel.org
>>>>> Suggested-by: Long Li <longli@microsoft.com>
>>>>> Suggested-by: Thomas Gleixner <tglx@kernel.org>
>>>>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>>>>>
>>>>>> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
>>>>>> index cfc8fa403dad6..89816a2bd7cd3 100644
>>>>>> --- a/drivers/pci/controller/pci-hyperv.c
>>>>>> +++ b/drivers/pci/controller/pci-hyperv.c
>>>>>> @@ -2119,6 +2119,7 @@ static bool hv_pcie_init_dev_msi_info(struct device *dev, struct irq_domain *dom
>>>>>>     	info->ops->msi_prepare = hv_msi_prepare;
>>>>>>     	chip->irq_set_affinity = irq_chip_set_affinity_parent;
>>>>>> +	chip->irq_retrigger = irq_chip_retrigger_hierarchy;
>>>>>
>>>>> [Severity: High]
>>>>> This isn't a bug introduced by this patch, but does the sister Hyper-V root
>>>>> partition MSI domain in arch/x86/hyperv/irqdomain.c also need this fix?
>>>>>
>>>>> Looking at hv_init_dev_msi_info(), it appears to be missing the exact same
>>>>> callback initialization for the root partition's top-level irq_chip:
>>>>>
>>>>> arch/x86/hyperv/irqdomain.c:hv_init_dev_msi_info() {
>>>>> 	...
>>>>> 	if (!msi_lib_init_dev_msi_info(dev, domain, real_parent, info))
>>>>> 		return false;
>>>>>
>>>>> 	chip->flags |= IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MOVE_DEFERRED;
>>>>>
>>>>> 	info->ops->msi_prepare = pci_msi_prepare;
>>>>>
>>>>> 	return true;
>>>>> }
>>>>>
>>>>> If a CPU is hot-unplugged while a device MSI interrupt is pending in its
>>>>> local APIC IRR, could fixup_irqs() fail to resend the pending interrupt
>>>>> to the new target CPU because this callback is NULL?
>>>>>
>>>>> This could potentially lead to the same lost interrupts and I/O stalls
>>>>> described in this commit message, just in the root partition MSI domain
>>>>> instead of the guest paravirtual MSI domain.
>>>>>
>>>>>>     	if (IS_ENABLED(CONFIG_X86))
>>>>>>     		chip->flags |= IRQCHIP_MOVE_DEFERRED;
>>>>>>
>>>>>
>>>>
>>>> I am not planning to include this in this series, since this issue is not
>>>> seen in root partition yet and I am not sure if it is applicable here.
>>>> Second patch would anyways fix it going forward, but I am OK adding the
>>>> change for this, if we need.
>>>
>>> What's the downside of fixing the root partition irq domain?
>>
>> No downside as such. It would be a latent bug, exposed only if we exercise
>> hotplug in root partition, which seems like we don't. After patch 2 of this
>> series, that would go away anyways. If you tell me, I can add a change
>> similar to patch 1, which is backportable, but then I would need to remove
>> it similarly in patch 3.
> 
> Yes, please fix that for the root partition, too. Being consistent
> across different use cases is going to save us some headache in the
> future.
> 
> Wei

Acked.

Regards,
Naman