[coreboot] [Xen-users] Enabling AMD-Vi IOMMU panics Xen

[小太]

On Tue, Mar 22, 2016 at 2:24 AM, Nick <nochristrequired at 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.html
)

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"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160323/5b7b099c/attachment.html>