[PATCH v3 0/3] x86/irq: Fix lost interrupts on CPU hot-unplug

[PATCH v3 0/3] x86/irq: Fix lost interrupts on CPU hot-unplug

[Naman Jain]

On CPU hot-unplug, fixup_irqs() re-injects interrupts that are still
pending in the outgoing CPU's IRR via the irqchip's irq_retrigger()
callback. The Hyper-V root partition PCI/MSI irqchip lost that callback
when it was converted to msi_create_parent_irq_domain(), so such a
pending interrupt is silently dropped, leading to lost interrupts, stalls
and "No irq handler for vector" messages.

Patch 1 is the minimal, backportable fix (Fixes:/Cc: stable) that restores
irq_chip_retrigger_hierarchy() on the Hyper-V root partition PCI/MSI chip.
The equivalent guest pci-hyperv.c fix from the previous version is already
merged, so it is dropped here.

Patch 2 then switches fixup_irqs() to have a fallback call to
irq_chip_retrigger_hierarchy() directly, if a chip does not define
irq_retrigger callback.

Patch 3 drops the now-redundant irq_retrigger() initializations.
This way, patch 2 and 3 do not need to be backported.

Changes since v2:
https://lore.kernel.org/all/20260810090716.2325295-1-namjain@linux.microsoft.com/
* Add a backportable fix for Hyper-V root partition irqchip (Wei)
* Add a check for custom irq_retrigger implementations and add direct
  irq_chip_retrigger_hierarchy() calls as a fallback if it is not
  defined by a chip. (Sashiko, Michael)
* Removed local loop variable change, and continue using the irq_desc
  accessor function (Michael)
* Did not pick "Acked-by: Manivannan Sadhasivam" as it was on v1, and v3
  is a functionally different to some extent, specially patch 2.
  Requesting you to please review again.

Changes since v1:
https://lore.kernel.org/all/20260728135117.2888175-1-namjain@linux.microsoft.com/#t
* Added Review tags
* Adding minor clarification in commit msg of patch 2 (Shradha)

Original RFC: https://lore.kernel.org/all/87y0f3jhd6.ffs@fw13/


Naman Jain (3):
  x86/hyperv: Set irq_retrigger for root partition PCI/MSI irqchip
  x86/irq: Fall back to irq_chip_retrigger_hierarchy() in fixup_irqs()
  x86/irq, iommu/amd, x86/hyperv, PCI: Drop redundant irq_retrigger
    inits

 arch/x86/kernel/apic/io_apic.c      |  2 --
 arch/x86/kernel/apic/msi.c          |  4 +---
 arch/x86/kernel/hpet.c              |  1 -
 arch/x86/kernel/irq.c               | 19 +++++++++++--------
 drivers/iommu/amd/init.c            |  1 -
 drivers/pci/controller/pci-hyperv.c |  1 -
 6 files changed, 12 insertions(+), 16 deletions(-)


base-commit: af5f12805e5cefa4fe68d6127c7e1fb78cd5535c
-- 
2.43.0

[PATCH v3 1/3] x86/hyperv: Set irq_retrigger for root partition PCI/MSI irqchip

[Naman Jain]

The Hyper-V root partition vPCI MSI irqchip lost its irq_retrigger()
callback when it was converted to msi_create_parent_irq_domain(). The
callback was present on the original irqchip and was dropped during that
conversion.

On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to
the outgoing CPU to a new target. If an interrupt still has its pending bit
set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the
new target through the irqchip's irq_retrigger() callback. As the root
partition PCI/MSI chip no longer provides that callback, the pending
interrupt is silently dropped, which can result in lost interrupts, stalls
and "No irq handler for vector" messages during CPU hotplug.

Restore irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for
the root partition PCI/MSI irqchip, so that a pending interrupt is resent
on its new target CPU via the parent x86 vector domain.

Fixes: 4691db0704ac ("x86/hyperv: Switch to msi_create_parent_irq_domain()")
Cc: stable@vger.kernel.org
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/x86/hyperv/irqdomain.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
index b3ad50a874dca..1e273d7d6c5b3 100644
--- a/arch/x86/hyperv/irqdomain.c
+++ b/arch/x86/hyperv/irqdomain.c
@@ -304,6 +304,7 @@ static struct irq_chip hv_pci_msi_controller = {
 	.irq_ack		= irq_chip_ack_parent,
 	.irq_compose_msi_msg	= hv_irq_compose_msi_msg,
 	.irq_set_affinity	= irq_chip_set_affinity_parent,
+	.irq_retrigger		= irq_chip_retrigger_hierarchy,
 };
 
 static bool hv_init_dev_msi_info(struct device *dev, struct irq_domain *domain,
-- 
2.43.0

RE: [PATCH v3 1/3] x86/hyperv: Set irq_retrigger for root partition PCI/MSI irqchip

[Michael Kelley]

From: Naman Jain <namjain@linux.microsoft.com> Sent: Sunday, September 6, 2026 11:51 PM
> 
> The Hyper-V root partition vPCI MSI irqchip lost its irq_retrigger()
> callback when it was converted to msi_create_parent_irq_domain(). The
> callback was present on the original irqchip and was dropped during that
> conversion.
> 
> On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to
> the outgoing CPU to a new target. If an interrupt still has its pending bit
> set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the
> new target through the irqchip's irq_retrigger() callback. As the root
> partition PCI/MSI chip no longer provides that callback, the pending
> interrupt is silently dropped, which can result in lost interrupts, stalls
> and "No irq handler for vector" messages during CPU hotplug.
> 
> Restore irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for
> the root partition PCI/MSI irqchip, so that a pending interrupt is resent
> on its new target CPU via the parent x86 vector domain.
> 
> Fixes: 4691db0704ac ("x86/hyperv: Switch to msi_create_parent_irq_domain()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  arch/x86/hyperv/irqdomain.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
> index b3ad50a874dca..1e273d7d6c5b3 100644
> --- a/arch/x86/hyperv/irqdomain.c
> +++ b/arch/x86/hyperv/irqdomain.c
> @@ -304,6 +304,7 @@ static struct irq_chip hv_pci_msi_controller = {
>  	.irq_ack		= irq_chip_ack_parent,
>  	.irq_compose_msi_msg	= hv_irq_compose_msi_msg,
>  	.irq_set_affinity	= irq_chip_set_affinity_parent,
> +	.irq_retrigger		= irq_chip_retrigger_hierarchy,
>  };

There's a slight discrepancy compared with the guest pci-hyperv.c driver,
where setting the .irq_retrigger function is done dynamically in
hv_pcie_init_dev_msi_info() instead of statically.  The parallel here would
be to set it in hv_init_dev_msi_info(). But given that Patch 3 of series
removes setting .irq_retrigger in both cases, the discrepancy shouldn't
really matter.

If there's a reason to prefer one approach vs. the other, I don't know
what that reason is.

Reviewed-by: Michael Kelley <mhklinux@outlook.com>

> 
>  static bool hv_init_dev_msi_info(struct device *dev, struct irq_domain *domain,
> --
> 2.43.0
> 

Re: [PATCH v3 1/3] x86/hyperv: Set irq_retrigger for root partition PCI/MSI irqchip

[Naman Jain]

On 9/8/2026 1:23 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Sunday, September 6, 2026 11:51 PM
>>
>> The Hyper-V root partition vPCI MSI irqchip lost its irq_retrigger()
>> callback when it was converted to msi_create_parent_irq_domain(). The
>> callback was present on the original irqchip and was dropped during that
>> conversion.
>>
>> On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to
>> the outgoing CPU to a new target. If an interrupt still has its pending bit
>> set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the
>> new target through the irqchip's irq_retrigger() callback. As the root
>> partition PCI/MSI chip no longer provides that callback, the pending
>> interrupt is silently dropped, which can result in lost interrupts, stalls
>> and "No irq handler for vector" messages during CPU hotplug.
>>
>> Restore irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for
>> the root partition PCI/MSI irqchip, so that a pending interrupt is resent
>> on its new target CPU via the parent x86 vector domain.
>>
>> Fixes: 4691db0704ac ("x86/hyperv: Switch to msi_create_parent_irq_domain()")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>>   arch/x86/hyperv/irqdomain.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
>> index b3ad50a874dca..1e273d7d6c5b3 100644
>> --- a/arch/x86/hyperv/irqdomain.c
>> +++ b/arch/x86/hyperv/irqdomain.c
>> @@ -304,6 +304,7 @@ static struct irq_chip hv_pci_msi_controller = {
>>   	.irq_ack		= irq_chip_ack_parent,
>>   	.irq_compose_msi_msg	= hv_irq_compose_msi_msg,
>>   	.irq_set_affinity	= irq_chip_set_affinity_parent,
>> +	.irq_retrigger		= irq_chip_retrigger_hierarchy,
>>   };
> 
> There's a slight discrepancy compared with the guest pci-hyperv.c driver,
> where setting the .irq_retrigger function is done dynamically in
> hv_pcie_init_dev_msi_info() instead of statically.  The parallel here would
> be to set it in hv_init_dev_msi_info(). But given that Patch 3 of series
> removes setting .irq_retrigger in both cases, the discrepancy shouldn't
> really matter.
> 
> If there's a reason to prefer one approach vs. the other, I don't know
> what that reason is.
> 
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>

This change should be done for the outermost chip, i.e. in
hv_init_dev_msi_info(). With change 2, it won't matter, but patch 2 is
not being back ported. So, I'll fix it.

Regards,
Naman

> 
>>
>>   static bool hv_init_dev_msi_info(struct device *dev, struct irq_domain *domain,
>> --
>> 2.43.0
>>
> 

RE: [PATCH v3 1/3] x86/hyperv: Set irq_retrigger for root partition PCI/MSI irqchip

[Nam Cao]

Michael Kelley <mhklinux@outlook.com> writes:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Sunday, September 6, 2026 11:51 PM
>> diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
>> index b3ad50a874dca..1e273d7d6c5b3 100644
>> --- a/arch/x86/hyperv/irqdomain.c
>> +++ b/arch/x86/hyperv/irqdomain.c
>> @@ -304,6 +304,7 @@ static struct irq_chip hv_pci_msi_controller = {
>>  	.irq_ack		= irq_chip_ack_parent,
>>  	.irq_compose_msi_msg	= hv_irq_compose_msi_msg,
>>  	.irq_set_affinity	= irq_chip_set_affinity_parent,
>> +	.irq_retrigger		= irq_chip_retrigger_hierarchy,
>>  };
>
> There's a slight discrepancy compared with the guest pci-hyperv.c driver,
> where setting the .irq_retrigger function is done dynamically in
> hv_pcie_init_dev_msi_info() instead of statically.  The parallel here would
> be to set it in hv_init_dev_msi_info(). But given that Patch 3 of series
> removes setting .irq_retrigger in both cases, the discrepancy shouldn't
> really matter.
>
> If there's a reason to prefer one approach vs. the other, I don't know
> what that reason is.

hv_pcie_init_dev_msi_info() is for the MSI device's interrupt domain,
while this patch is setting it for the parent's interrupt domain.

The former is what we need.

Nam

Re: [PATCH v3 1/3] x86/hyperv: Set irq_retrigger for root partition PCI/MSI irqchip

[Naman Jain]

On 9/8/2026 11:55 AM, Nam Cao wrote:
> Michael Kelley <mhklinux@outlook.com> writes:
>> From: Naman Jain <namjain@linux.microsoft.com> Sent: Sunday, September 6, 2026 11:51 PM
>>> diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
>>> index b3ad50a874dca..1e273d7d6c5b3 100644
>>> --- a/arch/x86/hyperv/irqdomain.c
>>> +++ b/arch/x86/hyperv/irqdomain.c
>>> @@ -304,6 +304,7 @@ static struct irq_chip hv_pci_msi_controller = {
>>>   	.irq_ack		= irq_chip_ack_parent,
>>>   	.irq_compose_msi_msg	= hv_irq_compose_msi_msg,
>>>   	.irq_set_affinity	= irq_chip_set_affinity_parent,
>>> +	.irq_retrigger		= irq_chip_retrigger_hierarchy,
>>>   };
>>
>> There's a slight discrepancy compared with the guest pci-hyperv.c driver,
>> where setting the .irq_retrigger function is done dynamically in
>> hv_pcie_init_dev_msi_info() instead of statically.  The parallel here would
>> be to set it in hv_init_dev_msi_info(). But given that Patch 3 of series
>> removes setting .irq_retrigger in both cases, the discrepancy shouldn't
>> really matter.
>>
>> If there's a reason to prefer one approach vs. the other, I don't know
>> what that reason is.
> 
> hv_pcie_init_dev_msi_info() is for the MSI device's interrupt domain,
> while this patch is setting it for the parent's interrupt domain.
> 
> The former is what we need.
> 
> Nam

Acked. I will push this change in next version.

Thanks,
Naman

[PATCH v3 2/3] x86/irq: Fall back to irq_chip_retrigger_hierarchy() in fixup_irqs()

[Naman Jain]

fixup_irqs() re-injects a pending interrupt on its new target CPU by
looking at the outermost domain chip and invoking its irq_retrigger()
callback directly. When the outermost chip does not implement
irq_retrigger(), the pending interrupt is silently dropped, which can
lead to lost interrupts on CPU hot-unplug.

Keep calling the outermost chip's irq_retrigger() when it is present,
but fall back to irq_chip_retrigger_hierarchy() otherwise, which walks
up the interrupt hierarchy until it finds a chip that implements
irq_retrigger().

While at it, use a scoped guard for desc->lock. VECTOR_RETRIGGERED is
now set only when the retrigger succeeds instead of unconditionally,
which is harmless today since apic_retrigger_irq() always returns 1.

Suggested-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/x86/kernel/irq.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 30122f0b3af96..e0163f7ac7368 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -470,6 +470,7 @@ void fixup_irqs(void)
 	struct irq_desc *desc;
 	struct irq_data *data;
 	struct irq_chip *chip;
+	int ret;
 
 	irq_migrate_all_off_this_cpu();
 
@@ -490,21 +491,23 @@ void fixup_irqs(void)
 	 * nothing else will touch it.
 	 */
 	for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS; vector++) {
-		if (IS_ERR_OR_NULL(__this_cpu_read(vector_irq[vector])))
+		desc = __this_cpu_read(vector_irq[vector]);
+
+		if (IS_ERR_OR_NULL(desc))
 			continue;
 
 		if (is_vector_pending(vector)) {
-			desc = __this_cpu_read(vector_irq[vector]);
-
-			raw_spin_lock(&desc->lock);
+			guard(raw_spinlock)(&desc->lock);
 			data = irq_desc_get_irq_data(desc);
 			chip = irq_data_get_irq_chip(data);
-			if (chip->irq_retrigger) {
-				chip->irq_retrigger(data);
+			if (chip->irq_retrigger)
+				ret = chip->irq_retrigger(data);
+			else
+				ret = irq_chip_retrigger_hierarchy(data);
+			if (ret)
 				__this_cpu_write(vector_irq[vector], VECTOR_RETRIGGERED);
-			}
-			raw_spin_unlock(&desc->lock);
 		}
+
 		if (__this_cpu_read(vector_irq[vector]) != VECTOR_RETRIGGERED)
 			__this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
 	}
-- 
2.43.0

Re: [PATCH v3 2/3] x86/irq: Fall back to irq_chip_retrigger_hierarchy() in fixup_irqs()

[Thomas Gleixner]

On Mon, Sep 07 2026 at 06:51, Naman Jain wrote:
> fixup_irqs() re-injects a pending interrupt on its new target CPU by
> looking at the outermost domain chip and invoking its irq_retrigger()
> callback directly. When the outermost chip does not implement
> irq_retrigger(), the pending interrupt is silently dropped, which can
> lead to lost interrupts on CPU hot-unplug.
>
> Keep calling the outermost chip's irq_retrigger() when it is present,
> but fall back to irq_chip_retrigger_hierarchy() otherwise, which walks
> up the interrupt hierarchy until it finds a chip that implements
> irq_retrigger().
>
> While at it, use a scoped guard for desc->lock. VECTOR_RETRIGGERED is
> now set only when the retrigger succeeds instead of unconditionally,
> which is harmless today since apic_retrigger_irq() always returns 1.
>
> Suggested-by: Thomas Gleixner <tglx@kernel.org>
> Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>

Reviewed-by: Thomas Gleixner <tglx@kernel.org>

RE: [PATCH v3 2/3] x86/irq: Fall back to irq_chip_retrigger_hierarchy() in fixup_irqs()

[Michael Kelley]

From: Naman Jain <namjain@linux.microsoft.com> Sent: Sunday, September 6, 2026 11:51 PM
> 
> fixup_irqs() re-injects a pending interrupt on its new target CPU by
> looking at the outermost domain chip and invoking its irq_retrigger()
> callback directly. When the outermost chip does not implement
> irq_retrigger(), the pending interrupt is silently dropped, which can
> lead to lost interrupts on CPU hot-unplug.
> 
> Keep calling the outermost chip's irq_retrigger() when it is present,
> but fall back to irq_chip_retrigger_hierarchy() otherwise, which walks
> up the interrupt hierarchy until it finds a chip that implements
> irq_retrigger().
> 
> While at it, use a scoped guard for desc->lock. VECTOR_RETRIGGERED is
> now set only when the retrigger succeeds instead of unconditionally,
> which is harmless today since apic_retrigger_irq() always returns 1.
> 
> Suggested-by: Thomas Gleixner <tglx@kernel.org>
> Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>

Reviewed-by: Michael Kelley <mhklinux@outlook.com>

> ---
>  arch/x86/kernel/irq.c | 19 +++++++++++--------
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
> index 30122f0b3af96..e0163f7ac7368 100644
> --- a/arch/x86/kernel/irq.c
> +++ b/arch/x86/kernel/irq.c
> @@ -470,6 +470,7 @@ void fixup_irqs(void)
>  	struct irq_desc *desc;
>  	struct irq_data *data;
>  	struct irq_chip *chip;
> +	int ret;
> 
>  	irq_migrate_all_off_this_cpu();
> 
> @@ -490,21 +491,23 @@ void fixup_irqs(void)
>  	 * nothing else will touch it.
>  	 */
>  	for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS; vector++) {
> -		if (IS_ERR_OR_NULL(__this_cpu_read(vector_irq[vector])))
> +		desc = __this_cpu_read(vector_irq[vector]);
> +
> +		if (IS_ERR_OR_NULL(desc))
>  			continue;
> 
>  		if (is_vector_pending(vector)) {
> -			desc = __this_cpu_read(vector_irq[vector]);
> -
> -			raw_spin_lock(&desc->lock);
> +			guard(raw_spinlock)(&desc->lock);
>  			data = irq_desc_get_irq_data(desc);
>  			chip = irq_data_get_irq_chip(data);
> -			if (chip->irq_retrigger) {
> -				chip->irq_retrigger(data);
> +			if (chip->irq_retrigger)
> +				ret = chip->irq_retrigger(data);
> +			else
> +				ret = irq_chip_retrigger_hierarchy(data);
> +			if (ret)
>  				__this_cpu_write(vector_irq[vector], VECTOR_RETRIGGERED);
> -			}
> -			raw_spin_unlock(&desc->lock);
>  		}
> +
>  		if (__this_cpu_read(vector_irq[vector]) != VECTOR_RETRIGGERED)
>  			__this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
>  	}
> --
> 2.43.0
> 

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

[Naman Jain]

With fixup_irqs() and the generic resend path (try_retrigger()) now both
falling back to irq_chip_retrigger_hierarchy(), installing it as the
irq_retrigger() callback on the outermost domain chips is no longer
required. The hierarchy walk reaches the x86 vector domain's
apic_retrigger_irq() for all of these stacked domain chips.

Remove the now redundant irq_retrigger() initializations from the outermost
domain interrupt chips, including the Hyper-V root partition PCI/MSI chip.
msi_set_affinity() is the only site that invoked the outermost chip's
irq_retrigger() directly. Convert it to irq_chip_retrigger_hierarchy() so
the x86_init_dev_msi_info() initialization can be dropped as well.

No functional change intended.

Suggested-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/x86/hyperv/irqdomain.c         | 1 -
 arch/x86/kernel/apic/io_apic.c      | 2 --
 arch/x86/kernel/apic/msi.c          | 4 +---
 arch/x86/kernel/hpet.c              | 1 -
 drivers/iommu/amd/init.c            | 1 -
 drivers/pci/controller/pci-hyperv.c | 1 -
 6 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
index 1e273d7d6c5b3..b3ad50a874dca 100644
--- a/arch/x86/hyperv/irqdomain.c
+++ b/arch/x86/hyperv/irqdomain.c
@@ -304,7 +304,6 @@ static struct irq_chip hv_pci_msi_controller = {
 	.irq_ack		= irq_chip_ack_parent,
 	.irq_compose_msi_msg	= hv_irq_compose_msi_msg,
 	.irq_set_affinity	= irq_chip_set_affinity_parent,
-	.irq_retrigger		= irq_chip_retrigger_hierarchy,
 };
 
 static bool hv_init_dev_msi_info(struct device *dev, struct irq_domain *domain,
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 7d7175d012288..18f49a251f23b 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1857,7 +1857,6 @@ static struct irq_chip ioapic_chip __read_mostly = {
 	.irq_ack		= irq_chip_ack_parent,
 	.irq_eoi		= ioapic_ack_level,
 	.irq_set_affinity	= ioapic_set_affinity,
-	.irq_retrigger		= irq_chip_retrigger_hierarchy,
 	.irq_get_irqchip_state	= ioapic_irq_get_chip_state,
 	.flags			= IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MOVE_DEFERRED |
 				  IRQCHIP_AFFINITY_PRE_STARTUP,
@@ -1871,7 +1870,6 @@ static struct irq_chip ioapic_ir_chip __read_mostly = {
 	.irq_ack		= irq_chip_ack_parent,
 	.irq_eoi		= ioapic_ir_ack_level,
 	.irq_set_affinity	= ioapic_set_affinity,
-	.irq_retrigger		= irq_chip_retrigger_hierarchy,
 	.irq_get_irqchip_state	= ioapic_irq_get_chip_state,
 	.flags			= IRQCHIP_SKIP_SET_WAKE |
 				  IRQCHIP_AFFINITY_PRE_STARTUP,
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 66bc5d3e79db3..aad2f15eb2176 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -137,7 +137,7 @@ msi_set_affinity(struct irq_data *irqd, const struct cpumask *mask, bool force)
 	 * IRR.
 	 */
 	if (lapic_vector_set_in_irr(cfg->vector))
-		irq_data_get_irq_chip(irqd)->irq_retrigger(irqd);
+		irq_chip_retrigger_hierarchy(irqd);
 
 	return ret;
 }
@@ -246,7 +246,6 @@ static bool x86_init_dev_msi_info(struct device *dev, struct irq_domain *domain,
 	info->ops->msi_prepare		= x86_msi_prepare;
 
 	info->chip->irq_ack		= irq_chip_ack_parent;
-	info->chip->irq_retrigger	= irq_chip_retrigger_hierarchy;
 	info->chip->flags		|= IRQCHIP_SKIP_SET_WAKE |
 					   IRQCHIP_AFFINITY_PRE_STARTUP;
 
@@ -313,7 +312,6 @@ static struct irq_chip dmar_msi_controller = {
 	.irq_mask		= dmar_msi_mask,
 	.irq_ack		= irq_chip_ack_parent,
 	.irq_set_affinity	= msi_domain_set_affinity,
-	.irq_retrigger		= irq_chip_retrigger_hierarchy,
 	.irq_compose_msi_msg	= dmar_msi_compose_msg,
 	.irq_write_msi_msg	= dmar_msi_write_msg,
 	.flags			= IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MOVE_DEFERRED |
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 8dc7b710e1250..2bb7a6f466af3 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -509,7 +509,6 @@ static struct irq_chip hpet_msi_controller __ro_after_init = {
 	.irq_mask = hpet_msi_mask,
 	.irq_ack = irq_chip_ack_parent,
 	.irq_set_affinity = msi_domain_set_affinity,
-	.irq_retrigger = irq_chip_retrigger_hierarchy,
 	.irq_write_msi_msg = hpet_msi_write_msg,
 	.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_AFFINITY_PRE_STARTUP,
 };
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 40726dfef2733..a19e1faf98750 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -2471,7 +2471,6 @@ static struct irq_chip intcapxt_controller = {
 	.irq_unmask		= intcapxt_unmask_irq,
 	.irq_mask		= intcapxt_mask_irq,
 	.irq_ack		= irq_chip_ack_parent,
-	.irq_retrigger		= irq_chip_retrigger_hierarchy,
 	.irq_set_affinity       = intcapxt_set_affinity,
 	.irq_set_wake		= intcapxt_set_wake,
 	.flags			= IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_MOVE_DEFERRED,
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 89816a2bd7cd3..cfc8fa403dad6 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -2119,7 +2119,6 @@ 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;
 
 	if (IS_ENABLED(CONFIG_X86))
 		chip->flags |= IRQCHIP_MOVE_DEFERRED;
-- 
2.43.0

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

[Thomas Gleixner]

On Mon, Sep 07 2026 at 06:51, Naman Jain wrote:

> With fixup_irqs() and the generic resend path (try_retrigger()) now both
> falling back to irq_chip_retrigger_hierarchy(), installing it as the
> irq_retrigger() callback on the outermost domain chips is no longer
> required. The hierarchy walk reaches the x86 vector domain's
> apic_retrigger_irq() for all of these stacked domain chips.
>
> Remove the now redundant irq_retrigger() initializations from the outermost
> domain interrupt chips, including the Hyper-V root partition PCI/MSI chip.
> msi_set_affinity() is the only site that invoked the outermost chip's
> irq_retrigger() directly. Convert it to irq_chip_retrigger_hierarchy() so
> the x86_init_dev_msi_info() initialization can be dropped as well.
>
> No functional change intended.
>
> Suggested-by: Thomas Gleixner <tglx@kernel.org>
> Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>

Reviewed-by: Thomas Gleixner <tglx@kernel.org>

RE: [PATCH v3 3/3] x86/irq, iommu/amd, x86/hyperv, PCI: Drop redundant irq_retrigger inits

[Michael Kelley]

From: Naman Jain <namjain@linux.microsoft.com> Sent: Sunday, September 6, 2026 11:51 PM
> 
> With fixup_irqs() and the generic resend path (try_retrigger()) now both
> falling back to irq_chip_retrigger_hierarchy(), installing it as the
> irq_retrigger() callback on the outermost domain chips is no longer
> required. The hierarchy walk reaches the x86 vector domain's
> apic_retrigger_irq() for all of these stacked domain chips.
> 
> Remove the now redundant irq_retrigger() initializations from the outermost
> domain interrupt chips, including the Hyper-V root partition PCI/MSI chip.
> msi_set_affinity() is the only site that invoked the outermost chip's
> irq_retrigger() directly. Convert it to irq_chip_retrigger_hierarchy() so
> the x86_init_dev_msi_info() initialization can be dropped as well.
> 
> No functional change intended.
> 
> Suggested-by: Thomas Gleixner <tglx@kernel.org>
> Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  arch/x86/hyperv/irqdomain.c         | 1 -
>  arch/x86/kernel/apic/io_apic.c      | 2 --
>  arch/x86/kernel/apic/msi.c          | 4 +---
>  arch/x86/kernel/hpet.c              | 1 -
>  drivers/iommu/amd/init.c            | 1 -
>  drivers/pci/controller/pci-hyperv.c | 1 -
>  6 files changed, 1 insertion(+), 9 deletions(-)
> 

[snip]

> diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
> index 66bc5d3e79db3..aad2f15eb2176 100644
> --- a/arch/x86/kernel/apic/msi.c
> +++ b/arch/x86/kernel/apic/msi.c
> @@ -137,7 +137,7 @@ msi_set_affinity(struct irq_data *irqd, const struct cpumask *mask, bool force)
>  	 * IRR.
>  	 */
>  	if (lapic_vector_set_in_irr(cfg->vector))
> -		irq_data_get_irq_chip(irqd)->irq_retrigger(irqd);
> +		irq_chip_retrigger_hierarchy(irqd);

In v2 of this patch series, I commented about whether this code
should also check for irq_retrigger() being set in the outermost
domain before calling irq_chip_retrigger_hierarchy(). fixup_irqs()
in Patch 2 of this series has that check, and I think it should be
here as well. While there are no domains in the x86 world today
that have a custom irq_retrigger function, I'll argue the check
should be done so the infrastructure is correct if such a domain
were added in the future.

Michael

> 
>  	return ret;
>  }
> @@ -246,7 +246,6 @@ static bool x86_init_dev_msi_info(struct device *dev, struct irq_domain *domain,
>  	info->ops->msi_prepare		= x86_msi_prepare;
> 
>  	info->chip->irq_ack		= irq_chip_ack_parent;
> -	info->chip->irq_retrigger	= irq_chip_retrigger_hierarchy;
>  	info->chip->flags		|= IRQCHIP_SKIP_SET_WAKE |
>  					   IRQCHIP_AFFINITY_PRE_STARTUP;
> 
> @@ -313,7 +312,6 @@ static struct irq_chip dmar_msi_controller = {
>  	.irq_mask		= dmar_msi_mask,
>  	.irq_ack		= irq_chip_ack_parent,
>  	.irq_set_affinity	= msi_domain_set_affinity,
> -	.irq_retrigger		= irq_chip_retrigger_hierarchy,
>  	.irq_compose_msi_msg	= dmar_msi_compose_msg,
>  	.irq_write_msi_msg	= dmar_msi_write_msg,
>  	.flags			= IRQCHIP_SKIP_SET_WAKE |  IRQCHIP_MOVE_DEFERRED |
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index 8dc7b710e1250..2bb7a6f466af3 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -509,7 +509,6 @@ static struct irq_chip hpet_msi_controller __ro_after_init = {
>  	.irq_mask = hpet_msi_mask,
>  	.irq_ack = irq_chip_ack_parent,
>  	.irq_set_affinity = msi_domain_set_affinity,
> -	.irq_retrigger = irq_chip_retrigger_hierarchy,
>  	.irq_write_msi_msg = hpet_msi_write_msg,
>  	.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_AFFINITY_PRE_STARTUP,
>  };
> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
> index 40726dfef2733..a19e1faf98750 100644
> --- a/drivers/iommu/amd/init.c
> +++ b/drivers/iommu/amd/init.c
> @@ -2471,7 +2471,6 @@ static struct irq_chip intcapxt_controller = {
>  	.irq_unmask		= intcapxt_unmask_irq,
>  	.irq_mask		= intcapxt_mask_irq,
>  	.irq_ack		= irq_chip_ack_parent,
> -	.irq_retrigger		= irq_chip_retrigger_hierarchy,
>  	.irq_set_affinity       = intcapxt_set_affinity,
>  	.irq_set_wake		= intcapxt_set_wake,
>  	.flags			= IRQCHIP_MASK_ON_SUSPEND |
> IRQCHIP_MOVE_DEFERRED,
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index 89816a2bd7cd3..cfc8fa403dad6 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -2119,7 +2119,6 @@ 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;
> 
>  	if (IS_ENABLED(CONFIG_X86))
>  		chip->flags |= IRQCHIP_MOVE_DEFERRED;
> --
> 2.43.0
> 

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

[Naman Jain]

On 9/8/2026 1:24 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Sunday, September 6, 2026 11:51 PM
>>
>> With fixup_irqs() and the generic resend path (try_retrigger()) now both
>> falling back to irq_chip_retrigger_hierarchy(), installing it as the
>> irq_retrigger() callback on the outermost domain chips is no longer
>> required. The hierarchy walk reaches the x86 vector domain's
>> apic_retrigger_irq() for all of these stacked domain chips.
>>
>> Remove the now redundant irq_retrigger() initializations from the outermost
>> domain interrupt chips, including the Hyper-V root partition PCI/MSI chip.
>> msi_set_affinity() is the only site that invoked the outermost chip's
>> irq_retrigger() directly. Convert it to irq_chip_retrigger_hierarchy() so
>> the x86_init_dev_msi_info() initialization can be dropped as well.
>>
>> No functional change intended.
>>
>> Suggested-by: Thomas Gleixner <tglx@kernel.org>
>> Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>>   arch/x86/hyperv/irqdomain.c         | 1 -
>>   arch/x86/kernel/apic/io_apic.c      | 2 --
>>   arch/x86/kernel/apic/msi.c          | 4 +---
>>   arch/x86/kernel/hpet.c              | 1 -
>>   drivers/iommu/amd/init.c            | 1 -
>>   drivers/pci/controller/pci-hyperv.c | 1 -
>>   6 files changed, 1 insertion(+), 9 deletions(-)
>>
> 
> [snip]
> 
>> diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
>> index 66bc5d3e79db3..aad2f15eb2176 100644
>> --- a/arch/x86/kernel/apic/msi.c
>> +++ b/arch/x86/kernel/apic/msi.c
>> @@ -137,7 +137,7 @@ msi_set_affinity(struct irq_data *irqd, const struct cpumask *mask, bool force)
>>   	 * IRR.
>>   	 */
>>   	if (lapic_vector_set_in_irr(cfg->vector))
>> -		irq_data_get_irq_chip(irqd)->irq_retrigger(irqd);
>> +		irq_chip_retrigger_hierarchy(irqd);
> 
> In v2 of this patch series, I commented about whether this code
> should also check for irq_retrigger() being set in the outermost
> domain before calling irq_chip_retrigger_hierarchy(). fixup_irqs()
> in Patch 2 of this series has that check, and I think it should be
> here as well. While there are no domains in the x86 world today
> that have a custom irq_retrigger function, I'll argue the check
> should be done so the infrastructure is correct if such a domain
> were added in the future.
> 
> Michael
> 

The reason I skipped changing this is because I realized that unlike
fixup_irqs(), this path is not generic, i.e. the chip you get here is
the same one as the one initialized in x86_init_dev_msi_info() below. So
someone adding a custom irq_retrigger function could simply change it in
above call site.
However, on looking at this again, I see if someone adds this custom
function again, it would be taken care of in fixup_irqs() but
msi_set_affinity() could silently be missed. I'll add the fallback soon
in next version.

Regards,
Naman

>>
>>   	return ret;
>>   }
>> @@ -246,7 +246,6 @@ static bool x86_init_dev_msi_info(struct device *dev, struct irq_domain *domain,
>>   	info->ops->msi_prepare		= x86_msi_prepare;
>>
>>   	info->chip->irq_ack		= irq_chip_ack_parent;
>> -	info->chip->irq_retrigger	= irq_chip_retrigger_hierarchy;
>>   	info->chip->flags		|= IRQCHIP_SKIP_SET_WAKE |
>>   					   IRQCHIP_AFFINITY_PRE_STARTUP;
>>
>> @@ -313,7 +312,6 @@ static struct irq_chip dmar_msi_controller = {
>>   	.irq_mask		= dmar_msi_mask,
>>   	.irq_ack		= irq_chip_ack_parent,
>>   	.irq_set_affinity	= msi_domain_set_affinity,
>> -	.irq_retrigger		= irq_chip_retrigger_hierarchy,
>>   	.irq_compose_msi_msg	= dmar_msi_compose_msg,
>>   	.irq_write_msi_msg	= dmar_msi_write_msg,
>>   	.flags			= IRQCHIP_SKIP_SET_WAKE |  IRQCHIP_MOVE_DEFERRED |
>> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
>> index 8dc7b710e1250..2bb7a6f466af3 100644
>> --- a/arch/x86/kernel/hpet.c
>> +++ b/arch/x86/kernel/hpet.c
>> @@ -509,7 +509,6 @@ static struct irq_chip hpet_msi_controller __ro_after_init = {
>>   	.irq_mask = hpet_msi_mask,
>>   	.irq_ack = irq_chip_ack_parent,
>>   	.irq_set_affinity = msi_domain_set_affinity,
>> -	.irq_retrigger = irq_chip_retrigger_hierarchy,
>>   	.irq_write_msi_msg = hpet_msi_write_msg,
>>   	.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_AFFINITY_PRE_STARTUP,
>>   };
>> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
>> index 40726dfef2733..a19e1faf98750 100644
>> --- a/drivers/iommu/amd/init.c
>> +++ b/drivers/iommu/amd/init.c
>> @@ -2471,7 +2471,6 @@ static struct irq_chip intcapxt_controller = {
>>   	.irq_unmask		= intcapxt_unmask_irq,
>>   	.irq_mask		= intcapxt_mask_irq,
>>   	.irq_ack		= irq_chip_ack_parent,
>> -	.irq_retrigger		= irq_chip_retrigger_hierarchy,
>>   	.irq_set_affinity       = intcapxt_set_affinity,
>>   	.irq_set_wake		= intcapxt_set_wake,
>>   	.flags			= IRQCHIP_MASK_ON_SUSPEND |
>> IRQCHIP_MOVE_DEFERRED,
>> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
>> index 89816a2bd7cd3..cfc8fa403dad6 100644
>> --- a/drivers/pci/controller/pci-hyperv.c
>> +++ b/drivers/pci/controller/pci-hyperv.c
>> @@ -2119,7 +2119,6 @@ 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;
>>
>>   	if (IS_ENABLED(CONFIG_X86))
>>   		chip->flags |= IRQCHIP_MOVE_DEFERRED;
>> --
>> 2.43.0
>>
>