[PATCH v1 0/3] iommu/amd: Fix and improve SB IOAPIC IVRS validation

[PATCH v1 0/3] iommu/amd: Fix and improve SB IOAPIC IVRS validation

[Wei Wang]

The check_ioapic_information() function validates that the Southbridge
(SB) IOAPIC is correctly listed in the IVRS table before enabling
Interrupt Remapping (IR). If validation fails, IR is disabled to avoid
IOMMU dropping interrupts from unmapped devices.

This series fixes three independent bugs in that function:

Patch 1 fixes a logic error where successfully detecting the SB IOAPIC
resets a 'ret' flag that was previously cleared by an unmapped secondary
(i.e., non-SB) IOAPIC. This causes IR to stay enabled when it should have
been disabled, leading to localized device hangs.

Patch 2 fixes a false positive: the SB IOAPIC was identified solely by
its devid matching the hardcoded value (00:14.0). If a buggy BIOS assigns
that devid to a secondary IOAPIC in the IVRS while the real SB IOAPIC gets
a different mapping, the check passes anyway and IR is left enabled. The
system timer's interrupts then get dropped by the IOMMU, causing a silent
boot hang. The fix identifies the SB IOAPIC by its APIC ID (the IOAPIC
that owns GSI 0) before matching its devid.

Patch 3 removes the hardcoded SB IOAPIC devid entirely and replaces it
with a dynamic PCI config‑space check. The SB IOAPIC resides in the FCH
(Fusion Controller Hub / Southbridge), which typically exposes itself as
an SMBus controller function. For example:

AMD Genoa:
00:14.0 SMBus: Advanced Micro Devices, Inc. FCH SMBus Controller

Hygon Gen4:
00:0b.0 SMBus: Chengdu Haiguang IC Design Co., Ltd. FCH SMBus Controller

The PCI class code at a given BDF is a stable, specification-defined
property. Using it to identify an FCH function avoids maintaining
per-vendor/per-generation hardcoded device IDs that must be updated for
new platforms, while producing the same safe fallback (IR disabled) if
the check ever fails.

Wei Wang (3):
  iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors
  iommu/amd: Fix false positive in SB IOAPIC IVRS validation
  iommu/amd: Dynamically verify Southbridge IOAPIC via PCI config space

 drivers/iommu/amd/init.c | 51 ++++++++++++++++++++++++++++++++++------
 1 file changed, 44 insertions(+), 7 deletions(-)


base-commit: 2febe6e6ee6e34c7754eff3c4d81aa7b0dcb7979
-- 
2.51.0

[PATCH v1 1/3] iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors

[Wei Wang]

The check_ioapic_information() function validates IOAPICs against the
IVRS table to safely disable Interrupt Remapping (IR) if the BIOS provides
a broken topology.

Currently, the validation loop contains a bug: If an unmapped secondary
IOAPIC is encountered, 'ret' is set to false. But if the Southbridge (SB)
IOAPIC is enumerated after it in the MADT, the loop overwrites 'ret' to
true.

This bypasses the validation failure and leaves IR enabled. When devices
attached to the unmapped secondary IOAPIC fire interrupts, the IOMMU drops
them due to the missing Requestor ID, leading to localized device hangs.

Fix this by initializing 'ret' to true and only toggling it to false
upon encountering a validation error, ensuring failures are never erased.

Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table")
Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
---
 drivers/iommu/amd/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 56ad020df494..ae9f1bc85375 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -3106,7 +3106,7 @@ static bool __init check_ioapic_information(void)
 	int idx;
 
 	has_sb_ioapic = false;
-	ret           = false;
+	ret           = true;
 
 	/*
 	 * If we have map overrides on the kernel command line the
@@ -3126,7 +3126,6 @@ static bool __init check_ioapic_information(void)
 			ret = false;
 		} else if (devid == IOAPIC_SB_DEVID) {
 			has_sb_ioapic = true;
-			ret           = true;
 		}
 	}
 
@@ -3140,6 +3139,7 @@ static bool __init check_ioapic_information(void)
 		 * device id for the IOAPIC in the system.
 		 */
 		pr_err("%s: No southbridge IOAPIC found\n", fw_bug);
+		ret = false;
 	}
 
 	if (!ret)
-- 
2.51.0

[PATCH v1 2/3] iommu/amd: Fix false positive in SB IOAPIC IVRS validation

[Wei Wang]

The check_ioapic_information() function is designed to prevent boot hangs
by ensuring the Southbridge (SB) IOAPIC is properly mapped in the IVRS
table before enabling Interrupt Remapping.

Currently, this check passes if *any* enumerated IOAPIC matches the
expected SB IOAPIC device ID. If a buggy BIOS assigns IOAPIC_SB_DEVID
(00:14.0) to a non-SB IOAPIC entry in the IVRS, while the actual SB IOAPIC
(APIC ID that owns GSI 0) gets a different or wrong devid, the check hits
a false positive and succeeds.

This erroneously enables Interrupt Remapping. Consequently, the IOMMU
blocks unmapped interrupts from the actual SB IOAPIC, dropping the system
timer and leading to a silent kernel boot hang.

Tighten the validation to verify the device ID specifically against the SB
IOAPIC by matching their APIC IDs first. This prevents the validation
check from being bypassed via device ID aliasing.

Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table")
Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
---
 drivers/iommu/amd/init.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index ae9f1bc85375..8981117417d6 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -3099,11 +3099,25 @@ static void __init free_iommu_resources(void)
 /* SB IOAPIC is always on this device in AMD systems */
 #define IOAPIC_SB_DEVID		((0x00 << 8) | PCI_DEVFN(0x14, 0))
 
+/*
+ * The Southbridge IOAPIC is assigned a GSI Base of 0 (handling interrupts
+ * 0 through 23).
+ */
+static int __init get_sb_ioapic_id(void)
+{
+	int idx = mp_find_ioapic(0);
+
+	if (idx < 0)
+		return -ENODEV;
+
+	return mpc_ioapic_id(idx);
+}
+
 static bool __init check_ioapic_information(void)
 {
 	const char *fw_bug = FW_BUG;
 	bool ret, has_sb_ioapic;
-	int idx;
+	int idx, sb_apicid;
 
 	has_sb_ioapic = false;
 	ret           = true;
@@ -3116,6 +3130,16 @@ static bool __init check_ioapic_information(void)
 	if (cmdline_maps)
 		fw_bug = "";
 
+	sb_apicid = get_sb_ioapic_id();
+	if (sb_apicid < 0) {
+		/*
+		 * Lack of SB IOAPIC registration is not a firmware bug,
+		 * e.g. kernel booted with noapic or noacpi.
+		 */
+		fw_bug = "";
+		goto out;
+	}
+
 	for (idx = 0; idx < nr_ioapics; idx++) {
 		int devid, id = mpc_ioapic_id(idx);
 
@@ -3124,11 +3148,11 @@ static bool __init check_ioapic_information(void)
 			pr_err("%s: IOAPIC[%d] not in IVRS table\n",
 				fw_bug, id);
 			ret = false;
-		} else if (devid == IOAPIC_SB_DEVID) {
+		} else if (id == sb_apicid && devid == IOAPIC_SB_DEVID) {
 			has_sb_ioapic = true;
 		}
 	}
-
+out:
 	if (!has_sb_ioapic) {
 		/*
 		 * We expect the SB IOAPIC to be listed in the IVRS
-- 
2.51.0

[PATCH v1 3/3] iommu/amd: Dynamically verify Southbridge IOAPIC via PCI config space

[Wei Wang]

check_ioapic_information() verifies whether the BIOS has provided a valid
device ID for the Southbridge (SB) IOAPIC in the IVRS table. Currently,
if the SB IOAPIC entry in the IVRS table does not match a historically
hardcoded device ID (00:14.0), interrupt remapping is forcibly disabled.

This hardcoded expectation does not scale to newer architectures. For
example, recent Hygon Gen 4 servers use 00:0b.0 for the SB IOAPIC,
causing the validation to fail and interrupt remapping to be permanently
disabled on these systems.

Because the SB IOAPIC is embedded within the FCH (Fusion Controller Hub)
and shares its device ID, we can inspect the PCI class code of the given
device ID to confirm it is an actual FCH device, which is typically
exposed as an SMBus controller function. The PCI class code at a given BDF
is a stable, specification-defined property. Using it to identify an FCH
function avoids maintaining per-vendor/per-generation hardcoded device IDs
that must be updated for new platforms, while producing the same safe
fallback (IR disabled) if the check ever fails.

Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
---
 drivers/iommu/amd/init.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 8981117417d6..a4930a946e68 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -3096,8 +3096,21 @@ static void __init free_iommu_resources(void)
 	free_pci_segments();
 }
 
-/* SB IOAPIC is always on this device in AMD systems */
-#define IOAPIC_SB_DEVID		((0x00 << 8) | PCI_DEVFN(0x14, 0))
+static bool __init check_sb_ioapic(int devid)
+{
+	u8 bus = PCI_BUS_NUM(devid);
+	u8 devfn = devid & 0xff;
+	u16 val;
+
+	val = read_pci_config_16(bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
+				 PCI_CLASS_DEVICE);
+
+	/*
+	 * The SB IOAPIC is integrated into the FCH (Southbridge), which is
+	 * typically exposed as an SMBus function in PCI config space.
+	 */
+	return val == PCI_CLASS_SERIAL_SMBUS;
+}
 
 /*
  * The Southbridge IOAPIC is assigned a GSI Base of 0 (handling interrupts
@@ -3148,7 +3161,7 @@ static bool __init check_ioapic_information(void)
 			pr_err("%s: IOAPIC[%d] not in IVRS table\n",
 				fw_bug, id);
 			ret = false;
-		} else if (id == sb_apicid && devid == IOAPIC_SB_DEVID) {
+		} else if (id == sb_apicid && check_sb_ioapic(devid)) {
 			has_sb_ioapic = true;
 		}
 	}
-- 
2.51.0

Re: [PATCH v1 0/3] iommu/amd: Fix and improve SB IOAPIC IVRS validation

[Jörg Rödel]

Suravee, Vasant, could you please have a look at this series?

Thanks,

	Joerg

On Mon, Apr 06, 2026 at 11:40:06PM +0800, Wei Wang wrote:
> The check_ioapic_information() function validates that the Southbridge
> (SB) IOAPIC is correctly listed in the IVRS table before enabling
> Interrupt Remapping (IR). If validation fails, IR is disabled to avoid
> IOMMU dropping interrupts from unmapped devices.
> 
> This series fixes three independent bugs in that function:
> 
> Patch 1 fixes a logic error where successfully detecting the SB IOAPIC
> resets a 'ret' flag that was previously cleared by an unmapped secondary
> (i.e., non-SB) IOAPIC. This causes IR to stay enabled when it should have
> been disabled, leading to localized device hangs.
> 
> Patch 2 fixes a false positive: the SB IOAPIC was identified solely by
> its devid matching the hardcoded value (00:14.0). If a buggy BIOS assigns
> that devid to a secondary IOAPIC in the IVRS while the real SB IOAPIC gets
> a different mapping, the check passes anyway and IR is left enabled. The
> system timer's interrupts then get dropped by the IOMMU, causing a silent
> boot hang. The fix identifies the SB IOAPIC by its APIC ID (the IOAPIC
> that owns GSI 0) before matching its devid.
> 
> Patch 3 removes the hardcoded SB IOAPIC devid entirely and replaces it
> with a dynamic PCI config‑space check. The SB IOAPIC resides in the FCH
> (Fusion Controller Hub / Southbridge), which typically exposes itself as
> an SMBus controller function. For example:
> 
> AMD Genoa:
> 00:14.0 SMBus: Advanced Micro Devices, Inc. FCH SMBus Controller
> 
> Hygon Gen4:
> 00:0b.0 SMBus: Chengdu Haiguang IC Design Co., Ltd. FCH SMBus Controller
> 
> The PCI class code at a given BDF is a stable, specification-defined
> property. Using it to identify an FCH function avoids maintaining
> per-vendor/per-generation hardcoded device IDs that must be updated for
> new platforms, while producing the same safe fallback (IR disabled) if
> the check ever fails.
> 
> Wei Wang (3):
>   iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors
>   iommu/amd: Fix false positive in SB IOAPIC IVRS validation
>   iommu/amd: Dynamically verify Southbridge IOAPIC via PCI config space
> 
>  drivers/iommu/amd/init.c | 51 ++++++++++++++++++++++++++++++++++------
>  1 file changed, 44 insertions(+), 7 deletions(-)
> 
> 
> base-commit: 2febe6e6ee6e34c7754eff3c4d81aa7b0dcb7979
> -- 
> 2.51.0
> 

Re: [PATCH v1 0/3] iommu/amd: Fix and improve SB IOAPIC IVRS validation

[Vasant Hegde]

Joerg,


On 5/11/2026 1:10 PM, Jörg Rödel wrote:
> Suravee, Vasant, could you please have a look at this series?

Sure. We are testing it internally. We will respond back this week.

-Vasant

Re: [PATCH v1 0/3] iommu/amd: Fix and improve SB IOAPIC IVRS validation

[徐勇伟]

On 5/18/2026 1:55 AM Vasant Hegde wrote:
>Joerg,
>
>
>On 5/11/2026 1:10 PM, Jörg Rödel wrote:
>> Suravee, Vasant, could you please have a look at this series?
>
>Sure. We are testing it internally. We will respond back this week.
>
>-Vasant

Tested-by: Yongwei Xu <xuyongwei@open-hieco.net>

I also tested the patchset on Hygon Gen 4 (7490) and AMD Genoa Servers. 

On Hygon 7490:
Without this patch: When the host boots, dmesg shows interrupt remapping is disabled due to the failure to find the SB IOAPIC:
[    8.871649] AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found
[    8.871653] AMD-Vi: Disabling interrupt remapping
[    8.872236] x2apic: IRQ remapping doesn't support X2APIC mode
[    8.872241] x2apic disabled

With this patchset applied: When the host boots, dmesg shows the APIC and interrupt remapping are successfully enabled:
[   15.795634] AMD-Vi: Interrupt remapping enabled
[   15.795639] AMD-Vi: X2APIC enabled
[   15.802112] AMD-Vi: Virtual APIC enabled

On AMD Genoa Server:
With this patchset applied, the host boots correctly with interrupt remapping enabled. A VM was launched and ran normally. No regressions were observed.

Re: [PATCH v1 1/3] iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors

[Vasant Hegde]

On 4/6/2026 9:10 PM, Wei Wang wrote:
> The check_ioapic_information() function validates IOAPICs against the
> IVRS table to safely disable Interrupt Remapping (IR) if the BIOS provides
> a broken topology.
> 
> Currently, the validation loop contains a bug: If an unmapped secondary
> IOAPIC is encountered, 'ret' is set to false. But if the Southbridge (SB)
> IOAPIC is enumerated after it in the MADT, the loop overwrites 'ret' to
> true.
> 
> This bypasses the validation failure and leaves IR enabled. When devices
> attached to the unmapped secondary IOAPIC fire interrupts, the IOMMU drops
> them due to the missing Requestor ID, leading to localized device hangs.
> 
> Fix this by initializing 'ret' to true and only toggling it to false
> upon encountering a validation error, ensuring failures are never erased.
> 
> Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table")
> Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>

Thanks for the fix.

Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>


-Vasant

Re: [PATCH v1 2/3] iommu/amd: Fix false positive in SB IOAPIC IVRS validation

[Vasant Hegde]

On 4/6/2026 9:10 PM, Wei Wang wrote:
> The check_ioapic_information() function is designed to prevent boot hangs
> by ensuring the Southbridge (SB) IOAPIC is properly mapped in the IVRS
> table before enabling Interrupt Remapping.
> 
> Currently, this check passes if *any* enumerated IOAPIC matches the
> expected SB IOAPIC device ID. If a buggy BIOS assigns IOAPIC_SB_DEVID
> (00:14.0) to a non-SB IOAPIC entry in the IVRS, while the actual SB IOAPIC
> (APIC ID that owns GSI 0) gets a different or wrong devid, the check hits
> a false positive and succeeds.
> 
> This erroneously enables Interrupt Remapping. Consequently, the IOMMU
> blocks unmapped interrupts from the actual SB IOAPIC, dropping the system
> timer and leading to a silent kernel boot hang.
> 
> Tighten the validation to verify the device ID specifically against the SB
> IOAPIC by matching their APIC IDs first. This prevents the validation
> check from being bypassed via device ID aliasing.
> 
> Fixes: c2ff5cf5294b ("iommu/amd: Work around wrong IOAPIC device-id in IVRS table")
> Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>


Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>


-Vasant

Re: [PATCH v1 3/3] iommu/amd: Dynamically verify Southbridge IOAPIC via PCI config space

[Vasant Hegde]

On 4/6/2026 9:10 PM, Wei Wang wrote:
> check_ioapic_information() verifies whether the BIOS has provided a valid
> device ID for the Southbridge (SB) IOAPIC in the IVRS table. Currently,
> if the SB IOAPIC entry in the IVRS table does not match a historically
> hardcoded device ID (00:14.0), interrupt remapping is forcibly disabled.
> 
> This hardcoded expectation does not scale to newer architectures. For
> example, recent Hygon Gen 4 servers use 00:0b.0 for the SB IOAPIC,
> causing the validation to fail and interrupt remapping to be permanently
> disabled on these systems.
> 
> Because the SB IOAPIC is embedded within the FCH (Fusion Controller Hub)
> and shares its device ID, we can inspect the PCI class code of the given
> device ID to confirm it is an actual FCH device, which is typically
> exposed as an SMBus controller function. The PCI class code at a given BDF
> is a stable, specification-defined property. Using it to identify an FCH
> function avoids maintaining per-vendor/per-generation hardcoded device IDs
> that must be updated for new platforms, while producing the same safe
> fallback (IR disabled) if the check ever fails.
> 
> Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>


Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>


-Vasant