summaryrefslogtreecommitdiffstats
path: root/drivers/iommu/amd_iommu.c
diff options
context:
space:
mode:
authorAlex Williamson <alex.williamson@redhat.com>2014-09-19 10:03:06 -0600
committerJoerg Roedel <jroedel@suse.de>2014-09-25 16:39:06 +0200
commitf096c061f5525d1b35a65b793057b52061dcb486 (patch)
tree9d79f925e4fc7820ea39686bd0bef3eb757891e6 /drivers/iommu/amd_iommu.c
parentd943b0ffba153cd63f836647b873b445842a2f58 (diff)
downloadlinux-f096c061f5525d1b35a65b793057b52061dcb486.tar.bz2
iommu: Rework iommu_group_get_for_pci_dev()
It turns out that our assumption that aliases are always to the same slot isn't true. One particular platform reports an IVRS alias of the SATA controller (00:11.0) for the legacy IDE controller (00:14.1). When we hit this, we attempt to use a single IOMMU group for everything on the same bus, which in this case is the root complex. We already have multiple groups defined for the root complex by this point, resulting in multiple WARN_ON hits. This patch makes these sorts of aliases work again with IOMMU groups by reworking how we search through the PCI address space to find existing groups. This should also now handle looped dependencies and all sorts of crazy inter-dependencies that we'll likely never see. The recursion used here should never be very deep. It's unlikely to have individual aliases and only theoretical that we'd ever see a chain where one alias causes us to search through to yet another alias. We're also only dealing with PCIe device on a single bus, which means we'll typically only see multiple slots in use on the root complex. Loops are also a theoretically possibility, which I've tested using fake DMA alias quirks and prevent from causing problems using a bitmap of the devfn space that's been visited. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Cc: stable@vger.kernel.org # 3.17 Signed-off-by: Joerg Roedel <jroedel@suse.de>
Diffstat (limited to 'drivers/iommu/amd_iommu.c')
0 files changed, 0 insertions, 0 deletions