On Tue, Mar 22, 2016 at 2:24 AM, Nick nochristrequired@gmail.com wrote:
Have you ever seen an IOAPIC (associated with a southbridge) that has a PCI device id?
I haven't seen one with a PCI device id... Although I only have experience with older southbridges - in this case, they were mapped to some fixed memory address (the range is probably configurable somewhere in the PCI configuration space, depending on the chipset.)
No, and from the IOMMU spec I linked, it suggests that it's not enumerable. I'm not sure *why* the IOMMU needs a PCI device IDs for the IOAPICs yet, but the system definitely can't boot with interrupt remapping enabled without knowing the IOAPIC device IDs.
That said, under normal usage (i.e., without the IOMMU on), they still are mapped to some fixed memory address.
(Here's the full thread on the xen-users mailing list for context: http://xen.1045712.n5.nabble.com/Enabling-AMD-Vi-IOMMU-panics-Xen-td5731305.... )
On the original issue, further investigation has shown that the non-northbridge (i.e., southbridge) IOAPIC is always mapped to 0xFEC00000 (Section 3.26.8 of the Family 16h Models 30h-3Fh BKDG), which from Xen's dmesg output would conclude it is IOAPIC[0] = IOAPIC #4, leaving the northbridge IOAPIC as IOAPIC[1] = IOAPIC #5.
From the information in the Linux and Xen source code, we know the
southbridge's IOAPIC is at the device ID 00:14.0, so half of the problem has been solved (Though I'm still interested in how we know it's at 00:14.0 - the two AMD IOMMU maintainers I emailed haven't replied yet)
I might try going through all the IDs that lspci lists on bus 00 to see if one works...
P.S., I just realised that "device ID" could also refer to the vendor:device ID pair, but in this case, I mean the bus ID (i.e, the bus:device.function triplet), which is what the IOMMU spec uses when they say "device ID"
-
小太