On Wed, 2014-05-14 at 12:34 +0200, Joerg Roedel wrote: > On Sat, May 10, 2014 at 09:03:11AM -0600, Alex Williamson wrote: > > The expectation is that the kernel and IVRS will produce the same > > result for topology based aliases while the kernel will also include > > device specific DMA quirks. > > Is that expectation really true? There are PCIe devices out there that > don't use their own device-id for requests but another one that isn't > even visible as a PCI device (so the kernel has no pci_dev structure for > it). The IVRS table contains such information, but I am not sure whether > the PCI core finds the right requestor-id for those devices. > > I've seen this on PCIe cards that where the vendor just used an PCI-X > chip with a PCIe-to-PCI-X bridge on the card. The PCI-X device is > visible for the OS but uses the requestor-id of the invisible bridge. If we rely on the IVRS, then the set of devices with quirked aliases is fixed by the platform vendor. More often than not, I think that proves to be ineffective. I personally have a 990FX box with a single function Marvell SATA controller that uses function 1 as the requester ID. It's running the latest BIOS and the IVRS isn't helping. With this series, we have the ability to add quirks to the kernel to fix those kinds of issues for both AMD-Vi, VT-d, and any other IOMMU. Here I've chosen that we get more value from using shared code so we don't process IOMMU groups in a unique way for AMD-Vi. Patch 09/15 uses the PCI core alias when the IVRS doesn't provide one, perhaps a compromise would be to also do the reverse and update dma_func_alias on the device when the IVRS knows of a device quirk that the kernel doesn't. Then we could still use the common IOMMU group code and print something to dmesg so that we can update the kernel quirks. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
