Re: [PATCH v2 3/3] x86/irq, iommu/amd, PCI: Drop redundant irq_retrigger inits

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

On 9/13/2026 12:36 AM, Thomas Gleixner wrote:
> On Fri, Sep 11 2026 at 16:32, Michael Kelley wrote:
>> From: Thomas Gleixner <tglx@kernel.org> Sent: Friday, September 11, 2026 1:12 AM
>> As for the future, you may remember my RFC patch set from a couple
>> years ago for the Synthetic Interrupt Controller (SynIC) that Hyper-V
>> provides to guests. The SynIC currently has special case nodes under
>> /sys/bus/vmbus to manage CPU affinity. As a better approach, the patch
>> set modelled the SynIC as an irqchip so standard Linux mechanisms could
>> manage affinity. You and I corresponded about per-cpu flow handler
>> tweaks to make it all work. The RFC patch set didn't get traction with
>> the Microsoft folks and I didn't push it. But it had a stand-alone IRQ
>> domain not parented to VECTOR because Hyper-V interrupts are hard
>> coded to HYPERVISOR_CALLBACK_VECTOR. As a stand-alone domain,
>> a .irq_retrigger function might have been useful in fixup_irqs(). That's
>> all speculative, but it was in the back of my head when I suggested to
>> Naman that the outermost chip .irq_retrigger function should be
>> checked. I'm fine with not doing that check now, and if a future case
>> like the Hyper-V SynIC arises, the check can be added.
> 
> It doesn't because that domain is not parented by the vector domain, so
> interrupts in that domain cannot have a descriptor in the descriptor
> array and neither will end up in msi_set_affinity().
> 
> These interrupts are handled in the generic cpuhotplug mechanism.
> 
> fixup_irqs() is really only about the vector domain to handle the case
> where an interrupt was raised on the old vector on the outgoing CPU
> before the generic hotplug affinity change took effect.
> 
>>> Devices might have a way to retrigger at the device level, but that's
>>> not reachable from the interrupt chip.
>>>
>>> So both places fixup_irq() and msi_set_affinity() can use retrigger
>>> hierarchy safely without the conditional checking the outermost domain
>>> chip.
>>
>> And setting .irq_retrigger in x86_init_dev_msi_info() becomes
>> superfluous, right?
> 
> Yes.
> 
> Thanks,
> 
>          tglx


I'll remove the conditional check in next version at both of the places.
Thanks.

Regards,
Naman