linux-kernel - [PATCH] Calgary: Find nearest matching Calgary while walking up the PCI tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091202014733.GD10295@tux1.beaverton.ibm.com>
Date:	Tue, 1 Dec 2009 17:47:33 -0800
From:	"Darrick J. Wong" <djwong@...ibm.com>
To:	Muli Ben-Yehuda <muli@...ibm.com>,
	"Jon D. Mason" <jdmason@...zu.us>
Cc:	discuss@...-64.org, linux-kernel <linux-kernel@...r.kernel.org>,
	Corinna Schultz <coschult@...ibm.com>
Subject: [PATCH] Calgary: Find nearest matching Calgary while walking up
	the PCI tree

On a multi-node x3950M2 system, there's a slight oddity in the PCI device tree
for all secondary nodes:

30:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
 \-33:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
    \-34:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)

...as compared to the primary node:

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
 \-01:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
03:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
 \-04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)

In both nodes, the LSI RAID controller hangs off a CalIOC2 device, but on the
secondary nodes, the BIOS hides the VGA device and substitutes the device tree
ending with the disk controller.

It would seem that Calgary devices don't necessarily appear at the top of the
PCI tree, which means that the current code to find the Calgary IOMMU that goes
with a particular device is buggy.  Rather than walk all the way to the top of
the PCI device tree and try to match bus number with Calgary descriptor, the
code needs to examine each parent of the particular device; if it encounters a
Calgary with a matching bus number, simply use that.  Otherwise, we BUG() when
the bus number of the Calgary doesn't match the bus number of whatever's at the
top of the device tree.

Signed-off-by: Darrick J. Wong <djwong@...ibm.com>
---

 arch/x86/kernel/pci-calgary_64.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)


diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index 971a3be..e6ec8a2 100644
--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -318,13 +318,15 @@ static inline struct iommu_table *find_iommu_table(struct device *dev)
 
 	pdev = to_pci_dev(dev);
 
+	/* search up the device tree for an iommu */
 	pbus = pdev->bus;
-
-	/* is the device behind a bridge? Look for the root bus */
-	while (pbus->parent)
+	do {
+		tbl = pci_iommu(pbus);
+		if (tbl && tbl->it_busno == pbus->number)
+			break;
+		tbl = NULL;
 		pbus = pbus->parent;
-
-	tbl = pci_iommu(pbus);
+	} while (pbus);
 
 	BUG_ON(tbl && (tbl->it_busno != pbus->number));
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/