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
