On 9/13/2026 12:36 AM, Thomas Gleixner wrote:
On Fri, Sep 11 2026 at 16:32, Michael Kelley wrote:
From: Thomas Gleixner <[email protected]> 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


Reply via email to