Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Mon, 2014-06-16 at 16:47 +0200, Joerg Roedel wrote: > Hi Alex, > > On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: > > Alex Williamson (16): > > PCI: Add DMA alias iterator > > PCI: define pci_dev_flags as bit shifts > > PCI: quirk pci_for_each_dma_alias() > > PCI: quirk dma_alias_devfn for Ricoh devices > > PCI: quirk dma_alias_devfn for Marvell devices > > PCI: Quirk pci_for_each_dma_alias() for bridges > > PCI: Add quirks for ASMedia and Tundra bridges > > iommu: Create central IOMMU group lookup/creation interface > > iommu/amd: Update to use PCI DMA aliases > > iommu/amd: Use iommu_group_get_for_dev() > > iommu/intel: Use iommu_group_get_for_dev() > > iommu/intel: Update to use PCI DMA aliases > > iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups > > iommu: Remove pci.h > > PCI: Remove pci_find_upstream_pcie_bridge() > > PCI: Remove pci_get_dma_source() > > Sorry for the delay, I had a look at the generic IOMMU and the AMD part > now. It looks good to me so far, but I still have to review the VT-d > changes and give it all some testing on my machines. I really like the > code simplification in the IOMMU drivers and also feel more comfortable > when the IVRS table is still taken into consideration for getting > aliases. Great, thanks Joerg. Let me know if you'd like a new series with just the IOMMU bits. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
Hi Alex, On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: > Alex Williamson (16): > PCI: Add DMA alias iterator > PCI: define pci_dev_flags as bit shifts > PCI: quirk pci_for_each_dma_alias() > PCI: quirk dma_alias_devfn for Ricoh devices > PCI: quirk dma_alias_devfn for Marvell devices > PCI: Quirk pci_for_each_dma_alias() for bridges > PCI: Add quirks for ASMedia and Tundra bridges > iommu: Create central IOMMU group lookup/creation interface > iommu/amd: Update to use PCI DMA aliases > iommu/amd: Use iommu_group_get_for_dev() > iommu/intel: Use iommu_group_get_for_dev() > iommu/intel: Update to use PCI DMA aliases > iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups > iommu: Remove pci.h > PCI: Remove pci_find_upstream_pcie_bridge() > PCI: Remove pci_get_dma_source() Sorry for the delay, I had a look at the generic IOMMU and the AMD part now. It looks good to me so far, but I still have to review the VT-d changes and give it all some testing on my machines. I really like the code simplification in the IOMMU drivers and also feel more comfortable when the IVRS table is still taken into consideration for getting aliases. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
Hi Alex, On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: Alex Williamson (16): PCI: Add DMA alias iterator PCI: define pci_dev_flags as bit shifts PCI: quirk pci_for_each_dma_alias() PCI: quirk dma_alias_devfn for Ricoh devices PCI: quirk dma_alias_devfn for Marvell devices PCI: Quirk pci_for_each_dma_alias() for bridges PCI: Add quirks for ASMedia and Tundra bridges iommu: Create central IOMMU group lookup/creation interface iommu/amd: Update to use PCI DMA aliases iommu/amd: Use iommu_group_get_for_dev() iommu/intel: Use iommu_group_get_for_dev() iommu/intel: Update to use PCI DMA aliases iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups iommu: Remove pci.h PCI: Remove pci_find_upstream_pcie_bridge() PCI: Remove pci_get_dma_source() Sorry for the delay, I had a look at the generic IOMMU and the AMD part now. It looks good to me so far, but I still have to review the VT-d changes and give it all some testing on my machines. I really like the code simplification in the IOMMU drivers and also feel more comfortable when the IVRS table is still taken into consideration for getting aliases. Joerg -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Mon, 2014-06-16 at 16:47 +0200, Joerg Roedel wrote: Hi Alex, On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: Alex Williamson (16): PCI: Add DMA alias iterator PCI: define pci_dev_flags as bit shifts PCI: quirk pci_for_each_dma_alias() PCI: quirk dma_alias_devfn for Ricoh devices PCI: quirk dma_alias_devfn for Marvell devices PCI: Quirk pci_for_each_dma_alias() for bridges PCI: Add quirks for ASMedia and Tundra bridges iommu: Create central IOMMU group lookup/creation interface iommu/amd: Update to use PCI DMA aliases iommu/amd: Use iommu_group_get_for_dev() iommu/intel: Use iommu_group_get_for_dev() iommu/intel: Update to use PCI DMA aliases iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups iommu: Remove pci.h PCI: Remove pci_find_upstream_pcie_bridge() PCI: Remove pci_get_dma_source() Sorry for the delay, I had a look at the generic IOMMU and the AMD part now. It looks good to me so far, but I still have to review the VT-d changes and give it all some testing on my machines. I really like the code simplification in the IOMMU drivers and also feel more comfortable when the IVRS table is still taken into consideration for getting aliases. Great, thanks Joerg. Let me know if you'd like a new series with just the IOMMU bits. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Thu, 2014-05-22 at 17:07 -0600, Alex Williamson wrote: > Alex Williamson (16): > PCI: Add DMA alias iterator > PCI: define pci_dev_flags as bit shifts > PCI: quirk pci_for_each_dma_alias() > PCI: quirk dma_alias_devfn for Ricoh devices > PCI: quirk dma_alias_devfn for Marvell devices > PCI: Quirk pci_for_each_dma_alias() for bridges > PCI: Add quirks for ASMedia and Tundra bridges Hi Joerg & David, Bjorn has accepted the above patches for v3.16 and they currently live in his pci/iommu branch. This series has been shown by numerous users to make devices with buggy DMA issues work in the presence of an IOMMU and it would be really great if we could get an opinion on both the common IOMMU changes as well as the changes for AMD-Vi and Intel VT-d. Varun has already ack'd the changes for fsl. Please let us know how you'd like to proceed. Can we get acks and allow Bjorn to shepherd the whole series in? Would you prefer to pull the changes via your respective trees and let Bjorn follow-up with the code removal? Do you have any outstanding issues with the patches to your areas? Thanks, Alex > iommu: Create central IOMMU group lookup/creation interface > iommu/amd: Update to use PCI DMA aliases > iommu/amd: Use iommu_group_get_for_dev() > iommu/intel: Use iommu_group_get_for_dev() > iommu/intel: Update to use PCI DMA aliases > iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups > iommu: Remove pci.h > PCI: Remove pci_find_upstream_pcie_bridge() > PCI: Remove pci_get_dma_source() > > > drivers/iommu/amd_iommu.c | 214 +++- > drivers/iommu/amd_iommu_types.h |1 > drivers/iommu/fsl_pamu_domain.c | 66 > drivers/iommu/intel-iommu.c | 307 > +-- > drivers/iommu/intel_irq_remapping.c | 55 -- > drivers/iommu/iommu.c | 181 + > drivers/iommu/pci.h | 29 --- > drivers/pci/quirks.c| 116 - > drivers/pci/search.c| 104 +--- > include/linux/iommu.h |1 > include/linux/pci.h | 31 +--- > 11 files changed, 557 insertions(+), 548 deletions(-) > delete mode 100644 drivers/iommu/pci.h > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Thu, 2014-05-22 at 17:07 -0600, Alex Williamson wrote: Alex Williamson (16): PCI: Add DMA alias iterator PCI: define pci_dev_flags as bit shifts PCI: quirk pci_for_each_dma_alias() PCI: quirk dma_alias_devfn for Ricoh devices PCI: quirk dma_alias_devfn for Marvell devices PCI: Quirk pci_for_each_dma_alias() for bridges PCI: Add quirks for ASMedia and Tundra bridges Hi Joerg David, Bjorn has accepted the above patches for v3.16 and they currently live in his pci/iommu branch. This series has been shown by numerous users to make devices with buggy DMA issues work in the presence of an IOMMU and it would be really great if we could get an opinion on both the common IOMMU changes as well as the changes for AMD-Vi and Intel VT-d. Varun has already ack'd the changes for fsl. Please let us know how you'd like to proceed. Can we get acks and allow Bjorn to shepherd the whole series in? Would you prefer to pull the changes via your respective trees and let Bjorn follow-up with the code removal? Do you have any outstanding issues with the patches to your areas? Thanks, Alex iommu: Create central IOMMU group lookup/creation interface iommu/amd: Update to use PCI DMA aliases iommu/amd: Use iommu_group_get_for_dev() iommu/intel: Use iommu_group_get_for_dev() iommu/intel: Update to use PCI DMA aliases iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups iommu: Remove pci.h PCI: Remove pci_find_upstream_pcie_bridge() PCI: Remove pci_get_dma_source() drivers/iommu/amd_iommu.c | 214 +++- drivers/iommu/amd_iommu_types.h |1 drivers/iommu/fsl_pamu_domain.c | 66 drivers/iommu/intel-iommu.c | 307 +-- drivers/iommu/intel_irq_remapping.c | 55 -- drivers/iommu/iommu.c | 181 + drivers/iommu/pci.h | 29 --- drivers/pci/quirks.c| 116 - drivers/pci/search.c| 104 +--- include/linux/iommu.h |1 include/linux/pci.h | 31 +--- 11 files changed, 557 insertions(+), 548 deletions(-) delete mode 100644 drivers/iommu/pci.h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Thu, May 29, 2014 at 4:29 AM, Bjorn Helgaas wrote: > On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: >> For testing, this version can be found in my git tree: >> >> git://github.com/awilliam/linux-vfio.git dma-alias-v4 >> >> Please report any issues. >> >> v4: >> - Change dma_func_alias to dma_alias_devfn, holding a single >>devfn to alias, thereby supporting aliases to the wrong slot. >>The DMA alias iterator is easily changed, but IOMMU grouping >>requires significant rework. This is now done in IOMMU code >>rather than PCI code. >> >> - AMD-Vi - try to incorporate IVRS aliases dynamically into >>PCI alias quirks to make sure that our grouping remains the >>same. Potentially this could end up reporting BIOS aliases >>that we can add to our list of quirks. >> >> v3: >> - Found several instances where I had PCI_SLOT when I meant >>PCI_FUNC. Thanks to Andrew for spotting this. This should >>fix the problem he was having with Ricoh quirks. We also >>pruned down the func0 quirks to only those that we know are >>needed. We can always add them back later. >> >> - Found a case in intel-iommu of using dev_is_pci() where I >>really wanted !dev_is_pci(). Fixed. >> >> v2: >> - Several new Marvell controllers added to quirks. There's been >>a lot of success reported with this series in >>https://bugzilla.kernel.org/show_bug.cgi?id=42679 >> >> - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do >>not expose a PCIe capability. These have been shown to use >>the standard PCIe-to-PCI bridge requester ID. >> >> - Fix copy/paste duplicate Ricoh quirk ID >> >> - Fixed AMD IOMMU for the "ghost" function case where the DMA >>alias is for an absent device. The iommu rlookup table and >>data fields need to be initializes. >> >> - Fixed Intel interrupt remapping, I wasn't passing the target >>bus number, only the alias bus number. >> >> These patches are split across PCI and IOMMU, but I've front-loaded >> all of the PCI infrastructure so that the first 7 patches can be >> applied to PCI-core, the IOMMU maintainers can pickup their patches, >> then we can finish with dead code removal. Bjorn might also be >> willing to carry the IOMMU changes if the maintainers want to ack >> them. > > I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest, > too, given acks from Joerg and David. Or if they prefer to take them all, > which might be easier than coordinating two trees, especially since there's > PCI stuff at the beginning and end, here's my ack for the PCI bits (patches > 1-7 and 15-16): > > Acked-by: Bjorn Helgaas > > If you want to send me updated changelogs for patches 5 & 6, I'll drop > those in. > > Didn't you have more testing reports? I see George's, but I thought there > were some others, too. > Tested-by: Andrew Cooks I've reviewed parts of this patch set, over multiple iterations, if that's worth anything. >> Original description: >> >> This series attempts to fix a couple issues we've had outstanding in >> the PCI/IOMMU code for a while. The first issue is with devices that >> use the wrong requester ID for DMA transactions. We already have a >> sort of half-baked attempt to fix this for several Ricoh devices, but >> the fix only helps them be useful through IOMMU groups, not the >> general DMA case. There are also several Marvell devices which use >> use a different wrong requester ID and don't even fit into the DMA >> source idea. This series creates a DMA alias iterator that will >> step through each possible alias of a device, allowing IOMMUs to >> insert mappings for both the device and its aliases. >> >> Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() >> function, which is known to blowup when it finds itself suddenly at >> a PCIe device without crossing a PCIe-to-PCI bridge (as identified by >> the PCIe capability). It also likes to make the invalid assumption >> that a PCIe device never has its requester ID masked by any usptream >> bus. We can fix this using the above new DMA alias iterator, since >> that's effectively what this function was meant to do. >> >> Finally, with all these helpers, it makes sense to consolidate code >> for determining IOMMU groups. The first step in finding the root >> of a group is finding the final upstream DMA alias for the device, >> then applying additional ACS rules and incorporating device specific >> aliases. As this is all common to PCI, create a single implementation >> and remove piles of code from the individual IOMMU drivers. >> >> This series allows devices like the Marvell 88SE9123 to finally work >> on Linux with either AMD-Vi or VT-d enabled on the box. I've >> collected device IDs from various bugs to support as many SKUs of >> these devices as possible, but I'm sure there are others that I've >> missed. >> >> This should also enable motherboards with an onboard ASmedia >>
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Thu, May 29, 2014 at 4:29 AM, Bjorn Helgaas bhelg...@google.com wrote: On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: For testing, this version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v4 Please report any issues. v4: - Change dma_func_alias to dma_alias_devfn, holding a single devfn to alias, thereby supporting aliases to the wrong slot. The DMA alias iterator is easily changed, but IOMMU grouping requires significant rework. This is now done in IOMMU code rather than PCI code. - AMD-Vi - try to incorporate IVRS aliases dynamically into PCI alias quirks to make sure that our grouping remains the same. Potentially this could end up reporting BIOS aliases that we can add to our list of quirks. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the ghost function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest, too, given acks from Joerg and David. Or if they prefer to take them all, which might be easier than coordinating two trees, especially since there's PCI stuff at the beginning and end, here's my ack for the PCI bits (patches 1-7 and 15-16): Acked-by: Bjorn Helgaas bhelg...@google.com If you want to send me updated changelogs for patches 5 6, I'll drop those in. Didn't you have more testing reports? I see George's, but I thought there were some others, too. Tested-by: Andrew Cooks aco...@linux.com I've reviewed parts of this patch set, over multiple iterations, if that's worth anything. Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are others that I've missed. This should also enable motherboards with an onboard ASmedia ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've acquired an adapter board with this chip, but it actually exposes a PCIe
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Wed, 2014-05-28 at 14:29 -0600, Bjorn Helgaas wrote: > On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: > > For testing, this version can be found in my git tree: > > > > git://github.com/awilliam/linux-vfio.git dma-alias-v4 > > > > Please report any issues. > > > > v4: > > - Change dma_func_alias to dma_alias_devfn, holding a single > >devfn to alias, thereby supporting aliases to the wrong slot. > >The DMA alias iterator is easily changed, but IOMMU grouping > >requires significant rework. This is now done in IOMMU code > >rather than PCI code. > > > > - AMD-Vi - try to incorporate IVRS aliases dynamically into > >PCI alias quirks to make sure that our grouping remains the > >same. Potentially this could end up reporting BIOS aliases > >that we can add to our list of quirks. > > > > v3: > > - Found several instances where I had PCI_SLOT when I meant > >PCI_FUNC. Thanks to Andrew for spotting this. This should > >fix the problem he was having with Ricoh quirks. We also > >pruned down the func0 quirks to only those that we know are > >needed. We can always add them back later. > > > > - Found a case in intel-iommu of using dev_is_pci() where I > >really wanted !dev_is_pci(). Fixed. > > > > v2: > > - Several new Marvell controllers added to quirks. There's been > >a lot of success reported with this series in > >https://bugzilla.kernel.org/show_bug.cgi?id=42679 > > > > - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do > >not expose a PCIe capability. These have been shown to use > >the standard PCIe-to-PCI bridge requester ID. > > > > - Fix copy/paste duplicate Ricoh quirk ID > > > > - Fixed AMD IOMMU for the "ghost" function case where the DMA > >alias is for an absent device. The iommu rlookup table and > >data fields need to be initializes. > > > > - Fixed Intel interrupt remapping, I wasn't passing the target > >bus number, only the alias bus number. > > > > These patches are split across PCI and IOMMU, but I've front-loaded > > all of the PCI infrastructure so that the first 7 patches can be > > applied to PCI-core, the IOMMU maintainers can pickup their patches, > > then we can finish with dead code removal. Bjorn might also be > > willing to carry the IOMMU changes if the maintainers want to ack > > them. > > I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest, > too, given acks from Joerg and David. Or if they prefer to take them all, > which might be easier than coordinating two trees, especially since there's > PCI stuff at the beginning and end, here's my ack for the PCI bits (patches > 1-7 and 15-16): > > Acked-by: Bjorn Helgaas Awesome, thanks! > If you want to send me updated changelogs for patches 5 & 6, I'll drop > those in. Yep, I'll send changelog updates for 5 & 6 in a few minutes. > Didn't you have more testing reports? I see George's, but I thought there > were some others, too. I also see: https://lkml.org/lkml/2014/5/28/24 Tested-by: Pat Erley There are several reports of success in the bzs, but I don't see any official tested-by tags there. Thanks, Alex > > Original description: > > > > This series attempts to fix a couple issues we've had outstanding in > > the PCI/IOMMU code for a while. The first issue is with devices that > > use the wrong requester ID for DMA transactions. We already have a > > sort of half-baked attempt to fix this for several Ricoh devices, but > > the fix only helps them be useful through IOMMU groups, not the > > general DMA case. There are also several Marvell devices which use > > use a different wrong requester ID and don't even fit into the DMA > > source idea. This series creates a DMA alias iterator that will > > step through each possible alias of a device, allowing IOMMUs to > > insert mappings for both the device and its aliases. > > > > Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() > > function, which is known to blowup when it finds itself suddenly at > > a PCIe device without crossing a PCIe-to-PCI bridge (as identified by > > the PCIe capability). It also likes to make the invalid assumption > > that a PCIe device never has its requester ID masked by any usptream > > bus. We can fix this using the above new DMA alias iterator, since > > that's effectively what this function was meant to do. > > > > Finally, with all these helpers, it makes sense to consolidate code > > for determining IOMMU groups. The first step in finding the root > > of a group is finding the final upstream DMA alias for the device, > > then applying additional ACS rules and incorporating device specific > > aliases. As this is all common to PCI, create a single implementation > > and remove piles of code from the individual IOMMU drivers. > > > > This series allows devices like the Marvell 88SE9123 to finally work > > on Linux with either AMD-Vi or VT-d enabled
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: > For testing, this version can be found in my git tree: > > git://github.com/awilliam/linux-vfio.git dma-alias-v4 > > Please report any issues. > > v4: > - Change dma_func_alias to dma_alias_devfn, holding a single >devfn to alias, thereby supporting aliases to the wrong slot. >The DMA alias iterator is easily changed, but IOMMU grouping >requires significant rework. This is now done in IOMMU code >rather than PCI code. > > - AMD-Vi - try to incorporate IVRS aliases dynamically into >PCI alias quirks to make sure that our grouping remains the >same. Potentially this could end up reporting BIOS aliases >that we can add to our list of quirks. > > v3: > - Found several instances where I had PCI_SLOT when I meant >PCI_FUNC. Thanks to Andrew for spotting this. This should >fix the problem he was having with Ricoh quirks. We also >pruned down the func0 quirks to only those that we know are >needed. We can always add them back later. > > - Found a case in intel-iommu of using dev_is_pci() where I >really wanted !dev_is_pci(). Fixed. > > v2: > - Several new Marvell controllers added to quirks. There's been >a lot of success reported with this series in >https://bugzilla.kernel.org/show_bug.cgi?id=42679 > > - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do >not expose a PCIe capability. These have been shown to use >the standard PCIe-to-PCI bridge requester ID. > > - Fix copy/paste duplicate Ricoh quirk ID > > - Fixed AMD IOMMU for the "ghost" function case where the DMA >alias is for an absent device. The iommu rlookup table and >data fields need to be initializes. > > - Fixed Intel interrupt remapping, I wasn't passing the target >bus number, only the alias bus number. > > These patches are split across PCI and IOMMU, but I've front-loaded > all of the PCI infrastructure so that the first 7 patches can be > applied to PCI-core, the IOMMU maintainers can pickup their patches, > then we can finish with dead code removal. Bjorn might also be > willing to carry the IOMMU changes if the maintainers want to ack > them. I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest, too, given acks from Joerg and David. Or if they prefer to take them all, which might be easier than coordinating two trees, especially since there's PCI stuff at the beginning and end, here's my ack for the PCI bits (patches 1-7 and 15-16): Acked-by: Bjorn Helgaas If you want to send me updated changelogs for patches 5 & 6, I'll drop those in. Didn't you have more testing reports? I see George's, but I thought there were some others, too. > Original description: > > This series attempts to fix a couple issues we've had outstanding in > the PCI/IOMMU code for a while. The first issue is with devices that > use the wrong requester ID for DMA transactions. We already have a > sort of half-baked attempt to fix this for several Ricoh devices, but > the fix only helps them be useful through IOMMU groups, not the > general DMA case. There are also several Marvell devices which use > use a different wrong requester ID and don't even fit into the DMA > source idea. This series creates a DMA alias iterator that will > step through each possible alias of a device, allowing IOMMUs to > insert mappings for both the device and its aliases. > > Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() > function, which is known to blowup when it finds itself suddenly at > a PCIe device without crossing a PCIe-to-PCI bridge (as identified by > the PCIe capability). It also likes to make the invalid assumption > that a PCIe device never has its requester ID masked by any usptream > bus. We can fix this using the above new DMA alias iterator, since > that's effectively what this function was meant to do. > > Finally, with all these helpers, it makes sense to consolidate code > for determining IOMMU groups. The first step in finding the root > of a group is finding the final upstream DMA alias for the device, > then applying additional ACS rules and incorporating device specific > aliases. As this is all common to PCI, create a single implementation > and remove piles of code from the individual IOMMU drivers. > > This series allows devices like the Marvell 88SE9123 to finally work > on Linux with either AMD-Vi or VT-d enabled on the box. I've > collected device IDs from various bugs to support as many SKUs of > these devices as possible, but I'm sure there are others that I've > missed. > > This should also enable motherboards with an onboard ASmedia > ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've > acquired an adapter board with this chip, but it actually exposes > a PCIe capability, unlike most of the onboard controllers. Therefore > I expect this series will fix the WARN_ON currently hit during boot, >
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: For testing, this version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v4 Please report any issues. v4: - Change dma_func_alias to dma_alias_devfn, holding a single devfn to alias, thereby supporting aliases to the wrong slot. The DMA alias iterator is easily changed, but IOMMU grouping requires significant rework. This is now done in IOMMU code rather than PCI code. - AMD-Vi - try to incorporate IVRS aliases dynamically into PCI alias quirks to make sure that our grouping remains the same. Potentially this could end up reporting BIOS aliases that we can add to our list of quirks. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the ghost function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest, too, given acks from Joerg and David. Or if they prefer to take them all, which might be easier than coordinating two trees, especially since there's PCI stuff at the beginning and end, here's my ack for the PCI bits (patches 1-7 and 15-16): Acked-by: Bjorn Helgaas bhelg...@google.com If you want to send me updated changelogs for patches 5 6, I'll drop those in. Didn't you have more testing reports? I see George's, but I thought there were some others, too. Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are others that I've missed. This should also enable motherboards with an onboard ASmedia ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've acquired an adapter board with this chip, but it actually exposes a PCIe capability, unlike most of the onboard controllers. Therefore I expect this series will fix the WARN_ON currently hit during boot, but there's a 50/50 chance whether the device behaves like a PCI bridge or a
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On Wed, 2014-05-28 at 14:29 -0600, Bjorn Helgaas wrote: On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote: For testing, this version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v4 Please report any issues. v4: - Change dma_func_alias to dma_alias_devfn, holding a single devfn to alias, thereby supporting aliases to the wrong slot. The DMA alias iterator is easily changed, but IOMMU grouping requires significant rework. This is now done in IOMMU code rather than PCI code. - AMD-Vi - try to incorporate IVRS aliases dynamically into PCI alias quirks to make sure that our grouping remains the same. Potentially this could end up reporting BIOS aliases that we can add to our list of quirks. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the ghost function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest, too, given acks from Joerg and David. Or if they prefer to take them all, which might be easier than coordinating two trees, especially since there's PCI stuff at the beginning and end, here's my ack for the PCI bits (patches 1-7 and 15-16): Acked-by: Bjorn Helgaas bhelg...@google.com Awesome, thanks! If you want to send me updated changelogs for patches 5 6, I'll drop those in. Yep, I'll send changelog updates for 5 6 in a few minutes. Didn't you have more testing reports? I see George's, but I thought there were some others, too. I also see: https://lkml.org/lkml/2014/5/28/24 Tested-by: Pat Erley pat-l...@erley.org There are several reports of success in the bzs, but I don't see any official tested-by tags there. Thanks, Alex Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On 05/22/2014 06:07 PM, Alex Williamson wrote: For testing, this version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v4 Please report any issues. v4: - Change dma_func_alias to dma_alias_devfn, holding a single devfn to alias, thereby supporting aliases to the wrong slot. The DMA alias iterator is easily changed, but IOMMU grouping requires significant rework. This is now done in IOMMU code rather than PCI code. - AMD-Vi - try to incorporate IVRS aliases dynamically into PCI alias quirks to make sure that our grouping remains the same. Potentially this could end up reporting BIOS aliases that we can add to our list of quirks. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the "ghost" function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are others that I've missed. This should also enable motherboards with an onboard ASmedia ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've acquired an adapter board with this chip, but it actually exposes a PCIe capability, unlike most of the onboard controllers. Therefore I expect this series will fix the WARN_ON currently hit during boot, but there's a 50/50 chance whether the device behaves like a PCI bridge or a PCIe bridge with regard to the requester ID that it uses to take ownership of the transaction. If it turns out to use the PCIe bridge model, I expect we can quirk it using a dev_flags bit to identify a PCI bridge that takes ownership as if it was a PCIe bridge. Please test and provide feedback. I expect IOMMU group topology should not change from this series, but if a case is found where it does, please share. Also, if there are additional quirks we need to add, please either file new or add to the existing bugs. Thanks, Alex --- Alex Williamson (16): PCI: Add DMA alias iterator PCI: define
Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
On 05/22/2014 06:07 PM, Alex Williamson wrote: For testing, this version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v4 Please report any issues. v4: - Change dma_func_alias to dma_alias_devfn, holding a single devfn to alias, thereby supporting aliases to the wrong slot. The DMA alias iterator is easily changed, but IOMMU grouping requires significant rework. This is now done in IOMMU code rather than PCI code. - AMD-Vi - try to incorporate IVRS aliases dynamically into PCI alias quirks to make sure that our grouping remains the same. Potentially this could end up reporting BIOS aliases that we can add to our list of quirks. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the ghost function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are others that I've missed. This should also enable motherboards with an onboard ASmedia ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've acquired an adapter board with this chip, but it actually exposes a PCIe capability, unlike most of the onboard controllers. Therefore I expect this series will fix the WARN_ON currently hit during boot, but there's a 50/50 chance whether the device behaves like a PCI bridge or a PCIe bridge with regard to the requester ID that it uses to take ownership of the transaction. If it turns out to use the PCIe bridge model, I expect we can quirk it using a dev_flags bit to identify a PCI bridge that takes ownership as if it was a PCIe bridge. Please test and provide feedback. I expect IOMMU group topology should not change from this series, but if a case is found where it does, please share. Also, if there are additional quirks we need to add, please either file new or add to the existing bugs. Thanks, Alex --- Alex Williamson (16): PCI: Add DMA alias iterator PCI: define
[PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
For testing, this version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v4 Please report any issues. v4: - Change dma_func_alias to dma_alias_devfn, holding a single devfn to alias, thereby supporting aliases to the wrong slot. The DMA alias iterator is easily changed, but IOMMU grouping requires significant rework. This is now done in IOMMU code rather than PCI code. - AMD-Vi - try to incorporate IVRS aliases dynamically into PCI alias quirks to make sure that our grouping remains the same. Potentially this could end up reporting BIOS aliases that we can add to our list of quirks. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the "ghost" function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are others that I've missed. This should also enable motherboards with an onboard ASmedia ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've acquired an adapter board with this chip, but it actually exposes a PCIe capability, unlike most of the onboard controllers. Therefore I expect this series will fix the WARN_ON currently hit during boot, but there's a 50/50 chance whether the device behaves like a PCI bridge or a PCIe bridge with regard to the requester ID that it uses to take ownership of the transaction. If it turns out to use the PCIe bridge model, I expect we can quirk it using a dev_flags bit to identify a PCI bridge that takes ownership as if it was a PCIe bridge. Please test and provide feedback. I expect IOMMU group topology should not change from this series, but if a case is found where it does, please share. Also, if there are additional quirks we need to add, please either file new or add to the existing bugs. Thanks, Alex --- Alex Williamson (16): PCI: Add DMA alias iterator PCI: define pci_dev_flags as bit shifts PCI: quirk pci_for_each_dma_alias() PCI:
[PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
For testing, this version can be found in my git tree: git://github.com/awilliam/linux-vfio.git dma-alias-v4 Please report any issues. v4: - Change dma_func_alias to dma_alias_devfn, holding a single devfn to alias, thereby supporting aliases to the wrong slot. The DMA alias iterator is easily changed, but IOMMU grouping requires significant rework. This is now done in IOMMU code rather than PCI code. - AMD-Vi - try to incorporate IVRS aliases dynamically into PCI alias quirks to make sure that our grouping remains the same. Potentially this could end up reporting BIOS aliases that we can add to our list of quirks. v3: - Found several instances where I had PCI_SLOT when I meant PCI_FUNC. Thanks to Andrew for spotting this. This should fix the problem he was having with Ricoh quirks. We also pruned down the func0 quirks to only those that we know are needed. We can always add them back later. - Found a case in intel-iommu of using dev_is_pci() where I really wanted !dev_is_pci(). Fixed. v2: - Several new Marvell controllers added to quirks. There's been a lot of success reported with this series in https://bugzilla.kernel.org/show_bug.cgi?id=42679 - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do not expose a PCIe capability. These have been shown to use the standard PCIe-to-PCI bridge requester ID. - Fix copy/paste duplicate Ricoh quirk ID - Fixed AMD IOMMU for the ghost function case where the DMA alias is for an absent device. The iommu rlookup table and data fields need to be initializes. - Fixed Intel interrupt remapping, I wasn't passing the target bus number, only the alias bus number. These patches are split across PCI and IOMMU, but I've front-loaded all of the PCI infrastructure so that the first 7 patches can be applied to PCI-core, the IOMMU maintainers can pickup their patches, then we can finish with dead code removal. Bjorn might also be willing to carry the IOMMU changes if the maintainers want to ack them. Original description: This series attempts to fix a couple issues we've had outstanding in the PCI/IOMMU code for a while. The first issue is with devices that use the wrong requester ID for DMA transactions. We already have a sort of half-baked attempt to fix this for several Ricoh devices, but the fix only helps them be useful through IOMMU groups, not the general DMA case. There are also several Marvell devices which use use a different wrong requester ID and don't even fit into the DMA source idea. This series creates a DMA alias iterator that will step through each possible alias of a device, allowing IOMMUs to insert mappings for both the device and its aliases. Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge() function, which is known to blowup when it finds itself suddenly at a PCIe device without crossing a PCIe-to-PCI bridge (as identified by the PCIe capability). It also likes to make the invalid assumption that a PCIe device never has its requester ID masked by any usptream bus. We can fix this using the above new DMA alias iterator, since that's effectively what this function was meant to do. Finally, with all these helpers, it makes sense to consolidate code for determining IOMMU groups. The first step in finding the root of a group is finding the final upstream DMA alias for the device, then applying additional ACS rules and incorporating device specific aliases. As this is all common to PCI, create a single implementation and remove piles of code from the individual IOMMU drivers. This series allows devices like the Marvell 88SE9123 to finally work on Linux with either AMD-Vi or VT-d enabled on the box. I've collected device IDs from various bugs to support as many SKUs of these devices as possible, but I'm sure there are others that I've missed. This should also enable motherboards with an onboard ASmedia ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've acquired an adapter board with this chip, but it actually exposes a PCIe capability, unlike most of the onboard controllers. Therefore I expect this series will fix the WARN_ON currently hit during boot, but there's a 50/50 chance whether the device behaves like a PCI bridge or a PCIe bridge with regard to the requester ID that it uses to take ownership of the transaction. If it turns out to use the PCIe bridge model, I expect we can quirk it using a dev_flags bit to identify a PCI bridge that takes ownership as if it was a PCIe bridge. Please test and provide feedback. I expect IOMMU group topology should not change from this series, but if a case is found where it does, please share. Also, if there are additional quirks we need to add, please either file new or add to the existing bugs. Thanks, Alex --- Alex Williamson (16): PCI: Add DMA alias iterator PCI: define pci_dev_flags as bit shifts PCI: quirk pci_for_each_dma_alias() PCI: quirk
