Re: [PATCH v2 2/3] x86/irq: Use irq_chip_retrigger_hierarchy() in fixup_irqs()

[Thomas Gleixner <tglx@kernel.org>]

On Thu, Aug 20 2026 at 10:17, Naman Jain wrote:
> On 8/19/2026 9:29 PM, Michael Kelley wrote:
> Config dependencies make sure that CONFIG_IRQ_DOMAIN_HIERARCHY is 
> defined wherever irq_chip_retrigger_hierarchy() is getting called.
>
> x86 SMP or x86-64 guarantees X86_LOCAL_APIC → IRQ_DOMAIN_HIERARCHY, 
> PCI_MSI guarantees it via GENERIC_MSI_IRQ. So the #ifdef may not be 
> required.

Correct. X86 depends hard on hierarchical interrupt domains.

> Can you please comment if you are OK with me adding this fallback 
> mechanism in next version.

I assume you talk about this:

    if (chip->irq_retrigger)
        ret = chip->irq_retrigger(data);
    else
        ret = irq_chip_retrigger_hierarchy(data);

It won't hurt, but I can't see a case where the outermost chip which
descends in the hierarchy down to the vector domain would need that at
all.

The point is that any interrupt which is connected to a APIC vector,
i.e. the interrupt descriptor is in the per CPU vector array, will have
the vector domain as root interrupt domain in its hierarchy. Otherwise
it would not end up there.

Therefore retriggering it at the vector domain level is the right thing
to do. The important point is that the retrigger happens on the new
target CPU to ensure that the interrupt which arrived late on the
outgoing CPU is not lost.

When you look at it from a device level (outermost domain), then that
entity sent the message off already and relies on the rest of the system
to take care of it.

That's what the vector level retrigger does. It ensures that the new
target CPU processes the interrupt and keeps the machinery going.

So yes, it looks "safer" with the fallback in theory, but in practice
it's a purely academic exercise.

Thanks,

        tglx