* [RFC 0/5] Clean up VMD DMA Map Ops @ 2019-12-31 20:24 Jon Derrick 2019-12-31 20:24 ` [RFC 1/5] iommu: Remove device link to group on failure Jon Derrick ` (5 more replies) 0 siblings, 6 replies; 19+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick Inspired by Christoph's last set: https://lkml.org/lkml/2019/8/28/667 VMD currently works with VT-d enabled by pointing DMA and IOMMU actions at the VMD endpoint. The problem with this approach is that the VMD endpoint's device-specific attributes, such as the dma mask, are used instead. This set cleans up VMD by removing the override that redirects dma map operations to the VMD endpoint. Instead it introduces a new dma alias mechanism into the existing dma alias infrastructure. Patch 1 and 2 are miscellaneous fixes discovered during development. Patch 1 is ready, but 2 likely doesn't go far enough for proper teardown on addition failure. Jon Derrick (5): iommu: Remove device link to group on failure iommu/vt-d: Unlink device if failed to add to group x86/PCI: Expose VMD's device in pci_sysdata PCI: vmd: Stop overriding dma_map_ops x86/PCI: Remove unused X86_DEV_DMA_OPS arch/x86/Kconfig | 3 - arch/x86/include/asm/device.h | 10 --- arch/x86/include/asm/pci.h | 4 +- arch/x86/pci/common.c | 44 ++---------- drivers/iommu/intel-iommu.c | 26 ++++--- drivers/iommu/iommu.c | 1 + drivers/pci/controller/Kconfig | 1 - drivers/pci/controller/vmd.c | 152 +---------------------------------------- drivers/pci/pci.c | 4 +- drivers/pci/search.c | 6 ++ include/linux/pci.h | 1 + 11 files changed, 37 insertions(+), 215 deletions(-) -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC 1/5] iommu: Remove device link to group on failure 2019-12-31 20:24 [RFC 0/5] Clean up VMD DMA Map Ops Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick 2020-01-01 3:59 ` Lu Baolu 2019-12-31 20:24 ` [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group Jon Derrick ` (4 subsequent siblings) 5 siblings, 1 reply; 19+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick This adds the missing teardown step that removes the device link from the group when the device addition fails. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- drivers/iommu/iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index d5174f0..3e35284 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -768,6 +768,7 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) mutex_unlock(&group->mutex); dev->iommu_group = NULL; kobject_put(group->devices_kobj); + sysfs_remove_link(group->devices_kobj, device->name); err_free_name: kfree(device->name); err_remove_link: -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC 1/5] iommu: Remove device link to group on failure 2019-12-31 20:24 ` [RFC 1/5] iommu: Remove device link to group on failure Jon Derrick @ 2020-01-01 3:59 ` Lu Baolu 0 siblings, 0 replies; 19+ messages in thread From: Lu Baolu @ 2020-01-01 3:59 UTC (permalink / raw) To: Jon Derrick, iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig Hi, On 1/1/20 4:24 AM, Jon Derrick wrote: > This adds the missing teardown step that removes the device link from > the group when the device addition fails. This change looks good to me. Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Best regards, baolu > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> > --- > drivers/iommu/iommu.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index d5174f0..3e35284 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -768,6 +768,7 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev) > mutex_unlock(&group->mutex); > dev->iommu_group = NULL; > kobject_put(group->devices_kobj); > + sysfs_remove_link(group->devices_kobj, device->name); > err_free_name: > kfree(device->name); > err_remove_link: > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2019-12-31 20:24 [RFC 0/5] Clean up VMD DMA Map Ops Jon Derrick 2019-12-31 20:24 ` [RFC 1/5] iommu: Remove device link to group on failure Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick 2020-01-01 4:05 ` Lu Baolu 2020-01-12 1:36 ` Lu Baolu 2019-12-31 20:24 ` [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata Jon Derrick ` (3 subsequent siblings) 5 siblings, 2 replies; 19+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick If the device fails to be added to the group, make sure to unlink the reference before returning. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- drivers/iommu/intel-iommu.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index b2526a4..978d502 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -5625,8 +5625,10 @@ static int intel_iommu_add_device(struct device *dev) group = iommu_group_get_for_dev(dev); - if (IS_ERR(group)) - return PTR_ERR(group); + if (IS_ERR(group)) { + ret = PTR_ERR(group); + goto unlink; + } iommu_group_put(group); @@ -5652,7 +5654,8 @@ static int intel_iommu_add_device(struct device *dev) if (!get_private_domain_for_dev(dev)) { dev_warn(dev, "Failed to get a private domain.\n"); - return -ENOMEM; + ret = -ENOMEM; + goto unlink; } dev_info(dev, @@ -5667,6 +5670,10 @@ static int intel_iommu_add_device(struct device *dev) } return 0; + +unlink: + iommu_device_unlink(&iommu->iommu, dev); + return ret; } static void intel_iommu_remove_device(struct device *dev) -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2019-12-31 20:24 ` [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group Jon Derrick @ 2020-01-01 4:05 ` Lu Baolu 2020-01-12 1:36 ` Lu Baolu 1 sibling, 0 replies; 19+ messages in thread From: Lu Baolu @ 2020-01-01 4:05 UTC (permalink / raw) To: Jon Derrick, iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On 1/1/20 4:24 AM, Jon Derrick wrote: > If the device fails to be added to the group, make sure to unlink the > reference before returning. > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> This fix looks reasonable to me. Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Best regards, baolu > --- > drivers/iommu/intel-iommu.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c > index b2526a4..978d502 100644 > --- a/drivers/iommu/intel-iommu.c > +++ b/drivers/iommu/intel-iommu.c > @@ -5625,8 +5625,10 @@ static int intel_iommu_add_device(struct device *dev) > > group = iommu_group_get_for_dev(dev); > > - if (IS_ERR(group)) > - return PTR_ERR(group); > + if (IS_ERR(group)) { > + ret = PTR_ERR(group); > + goto unlink; > + } > > iommu_group_put(group); > > @@ -5652,7 +5654,8 @@ static int intel_iommu_add_device(struct device *dev) > if (!get_private_domain_for_dev(dev)) { > dev_warn(dev, > "Failed to get a private domain.\n"); > - return -ENOMEM; > + ret = -ENOMEM; > + goto unlink; > } > > dev_info(dev, > @@ -5667,6 +5670,10 @@ static int intel_iommu_add_device(struct device *dev) > } > > return 0; > + > +unlink: > + iommu_device_unlink(&iommu->iommu, dev); > + return ret; > } > > static void intel_iommu_remove_device(struct device *dev) > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2019-12-31 20:24 ` [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group Jon Derrick 2020-01-01 4:05 ` Lu Baolu @ 2020-01-12 1:36 ` Lu Baolu 2020-01-13 12:20 ` Joerg Roedel 1 sibling, 1 reply; 19+ messages in thread From: Lu Baolu @ 2020-01-12 1:36 UTC (permalink / raw) To: Jon Derrick, iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On 1/1/20 4:24 AM, Jon Derrick wrote: > If the device fails to be added to the group, make sure to unlink the > reference before returning. > > Signed-off-by: Jon Derrick<jonathan.derrick@intel.com> Queued for v5.6. Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2020-01-12 1:36 ` Lu Baolu @ 2020-01-13 12:20 ` Joerg Roedel 2020-01-14 1:58 ` Lu Baolu 0 siblings, 1 reply; 19+ messages in thread From: Joerg Roedel @ 2020-01-13 12:20 UTC (permalink / raw) To: Lu Baolu Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick On Sun, Jan 12, 2020 at 09:36:56AM +0800, Lu Baolu wrote: > On 1/1/20 4:24 AM, Jon Derrick wrote: > > If the device fails to be added to the group, make sure to unlink the > > reference before returning. > > > > Signed-off-by: Jon Derrick<jonathan.derrick@intel.com> > > Queued for v5.6. No need to do so, I sent it upstream with the last pile of iommu fixes. Thanks, Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group 2020-01-13 12:20 ` Joerg Roedel @ 2020-01-14 1:58 ` Lu Baolu 0 siblings, 0 replies; 19+ messages in thread From: Lu Baolu @ 2020-01-14 1:58 UTC (permalink / raw) To: Joerg Roedel Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick On 1/13/20 8:20 PM, Joerg Roedel wrote: > On Sun, Jan 12, 2020 at 09:36:56AM +0800, Lu Baolu wrote: >> On 1/1/20 4:24 AM, Jon Derrick wrote: >>> If the device fails to be added to the group, make sure to unlink the >>> reference before returning. >>> >>> Signed-off-by: Jon Derrick<jonathan.derrick@intel.com> >> >> Queued for v5.6. > > No need to do so, I sent it upstream with the last pile of iommu fixes. Got it. Thank you! Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata 2019-12-31 20:24 [RFC 0/5] Clean up VMD DMA Map Ops Jon Derrick 2019-12-31 20:24 ` [RFC 1/5] iommu: Remove device link to group on failure Jon Derrick 2019-12-31 20:24 ` [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick 2020-01-09 14:33 ` Christoph Hellwig 2019-12-31 20:24 ` [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops Jon Derrick ` (2 subsequent siblings) 5 siblings, 1 reply; 19+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick To be used by intel-iommu code to find the correct domain. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- arch/x86/include/asm/pci.h | 4 ++-- drivers/pci/controller/vmd.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h index 90d0731..7656807 100644 --- a/arch/x86/include/asm/pci.h +++ b/arch/x86/include/asm/pci.h @@ -25,7 +25,7 @@ struct pci_sysdata { void *fwnode; /* IRQ domain for MSI assignment */ #endif #if IS_ENABLED(CONFIG_VMD) - bool vmd_domain; /* True if in Intel VMD domain */ + struct device *vmd_dev; /* Non-null if in Intel VMD domain */ #endif }; @@ -65,7 +65,7 @@ static inline bool is_vmd(struct pci_bus *bus) #if IS_ENABLED(CONFIG_VMD) struct pci_sysdata *sd = bus->sysdata; - return sd->vmd_domain; + return !!sd->vmd_dev; #else return false; #endif diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index 2128422..907b5bd 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -679,7 +679,7 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) .parent = res, }; - sd->vmd_domain = true; + sd->vmd_dev = &vmd->dev->dev; sd->domain = vmd_find_free_domain(); if (sd->domain < 0) return sd->domain; -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata 2019-12-31 20:24 ` [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata Jon Derrick @ 2020-01-09 14:33 ` Christoph Hellwig 2020-01-09 15:06 ` Derrick, Jonathan 2020-01-09 16:45 ` Derrick, Jonathan 0 siblings, 2 replies; 19+ messages in thread From: Christoph Hellwig @ 2020-01-09 14:33 UTC (permalink / raw) To: Jon Derrick Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote: > To be used by intel-iommu code to find the correct domain. Any reason to prefer this version over my patches 2 and 3 from the series in August? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata 2020-01-09 14:33 ` Christoph Hellwig @ 2020-01-09 15:06 ` Derrick, Jonathan 2020-01-09 16:45 ` Derrick, Jonathan 1 sibling, 0 replies; 19+ messages in thread From: Derrick, Jonathan @ 2020-01-09 15:06 UTC (permalink / raw) To: hch; +Cc: linux-pci, iommu, helgaas, kbusch, dwmw2 On Thu, 2020-01-09 at 15:33 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote: > > To be used by intel-iommu code to find the correct domain. > > Any reason to prefer this version over my patches 2 and 3 from the > series in August? Mine uses the correct device's dma mask _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata 2020-01-09 14:33 ` Christoph Hellwig 2020-01-09 15:06 ` Derrick, Jonathan @ 2020-01-09 16:45 ` Derrick, Jonathan 1 sibling, 0 replies; 19+ messages in thread From: Derrick, Jonathan @ 2020-01-09 16:45 UTC (permalink / raw) To: hch; +Cc: linux-pci, iommu, helgaas, kbusch, dwmw2 On Thu, 2020-01-09 at 15:33 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:21PM -0700, Jon Derrick wrote: > > To be used by intel-iommu code to find the correct domain. > > Any reason to prefer this version over my patches 2 and 3 from the > series in August? 2 & 3 of your set is fine. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops 2019-12-31 20:24 [RFC 0/5] Clean up VMD DMA Map Ops Jon Derrick ` (2 preceding siblings ...) 2019-12-31 20:24 ` [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick 2020-01-09 14:36 ` Christoph Hellwig 2019-12-31 20:24 ` [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS Jon Derrick 2020-01-07 13:41 ` [RFC 0/5] Clean up VMD DMA Map Ops Joerg Roedel 5 siblings, 1 reply; 19+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick Devices on the VMD domain use the VMD endpoint's requester-id and have been relying on the VMD endpoint's dma operations. The downside of this was that VMD domain devices would use the VMD endpoint's attributes when doing DMA and IOMMU mapping. We can be smarter about this by only using the VMD endpoint when mapping and providing the correct child device's attributes during dma operations. This patch adds a new dma alias mechanism by adding a hint to a pci_dev to point to a singular DMA requester's pci_dev. This integrates into the existing dma alias infrastructure to reduce the impact of the changes required to support this mode. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- arch/x86/pci/common.c | 6 +- drivers/iommu/intel-iommu.c | 13 ++-- drivers/pci/controller/Kconfig | 1 - drivers/pci/controller/vmd.c | 150 ----------------------------------------- drivers/pci/pci.c | 4 +- drivers/pci/search.c | 6 ++ include/linux/pci.h | 1 + 7 files changed, 23 insertions(+), 158 deletions(-) diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c index 1e59df0..4022609 100644 --- a/arch/x86/pci/common.c +++ b/arch/x86/pci/common.c @@ -664,8 +664,12 @@ static void set_dma_domain_ops(struct pci_dev *pdev) {} static void set_dev_domain_options(struct pci_dev *pdev) { - if (is_vmd(pdev->bus)) + if (is_vmd(pdev->bus)) { + struct pci_sysdata *sd = pdev->bus->sysdata; + + pdev->dma_parent = to_pci_dev(sd->vmd_dev); pdev->hotplug_user_indicators = 1; + } } int pcibios_add_device(struct pci_dev *dev) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 978d502..5aee648 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -776,11 +776,8 @@ static struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devf pdev = to_pci_dev(dev); -#ifdef CONFIG_X86 - /* VMD child devices currently cannot be handled individually */ - if (is_vmd(pdev->bus)) - return NULL; -#endif + if (pdev->dma_parent) + pdev = pdev->dma_parent; /* VFs aren't listed in scope tables; we need to look up * the PF instead to find the IOMMU. */ @@ -2428,6 +2425,12 @@ static struct dmar_domain *find_domain(struct device *dev) dev->archdata.iommu == DUMMY_DEVICE_DOMAIN_INFO)) return NULL; + if (dev_is_pci(dev)) { + struct pci_dev *pdev = to_pci_dev(dev); + if (pdev->dma_parent) + dev = &pdev->dma_parent->dev; + } + /* No lock here, assumes no domain exit in normal case */ info = dev->archdata.iommu; if (likely(info)) diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig index c77069c..55671429 100644 --- a/drivers/pci/controller/Kconfig +++ b/drivers/pci/controller/Kconfig @@ -239,7 +239,6 @@ config PCIE_TANGO_SMP8759 config VMD depends on PCI_MSI && X86_64 && SRCU - select X86_DEV_DMA_OPS tristate "Intel Volume Management Device Driver" ---help--- Adds support for the Intel Volume Management Device (VMD). VMD is a diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index 907b5bd..5824a39 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -98,9 +98,6 @@ struct vmd_dev { struct irq_domain *irq_domain; struct pci_bus *bus; u8 busn_start; - - struct dma_map_ops dma_ops; - struct dma_domain dma_domain; }; static inline struct vmd_dev *vmd_from_bus(struct pci_bus *bus) @@ -295,151 +292,6 @@ static void vmd_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc) .chip = &vmd_msi_controller, }; -/* - * VMD replaces the requester ID with its own. DMA mappings for devices in a - * VMD domain need to be mapped for the VMD, not the device requiring - * the mapping. - */ -static struct device *to_vmd_dev(struct device *dev) -{ - struct pci_dev *pdev = to_pci_dev(dev); - struct vmd_dev *vmd = vmd_from_bus(pdev->bus); - - return &vmd->dev->dev; -} - -static void *vmd_alloc(struct device *dev, size_t size, dma_addr_t *addr, - gfp_t flag, unsigned long attrs) -{ - return dma_alloc_attrs(to_vmd_dev(dev), size, addr, flag, attrs); -} - -static void vmd_free(struct device *dev, size_t size, void *vaddr, - dma_addr_t addr, unsigned long attrs) -{ - return dma_free_attrs(to_vmd_dev(dev), size, vaddr, addr, attrs); -} - -static int vmd_mmap(struct device *dev, struct vm_area_struct *vma, - void *cpu_addr, dma_addr_t addr, size_t size, - unsigned long attrs) -{ - return dma_mmap_attrs(to_vmd_dev(dev), vma, cpu_addr, addr, size, - attrs); -} - -static int vmd_get_sgtable(struct device *dev, struct sg_table *sgt, - void *cpu_addr, dma_addr_t addr, size_t size, - unsigned long attrs) -{ - return dma_get_sgtable_attrs(to_vmd_dev(dev), sgt, cpu_addr, addr, size, - attrs); -} - -static dma_addr_t vmd_map_page(struct device *dev, struct page *page, - unsigned long offset, size_t size, - enum dma_data_direction dir, - unsigned long attrs) -{ - return dma_map_page_attrs(to_vmd_dev(dev), page, offset, size, dir, - attrs); -} - -static void vmd_unmap_page(struct device *dev, dma_addr_t addr, size_t size, - enum dma_data_direction dir, unsigned long attrs) -{ - dma_unmap_page_attrs(to_vmd_dev(dev), addr, size, dir, attrs); -} - -static int vmd_map_sg(struct device *dev, struct scatterlist *sg, int nents, - enum dma_data_direction dir, unsigned long attrs) -{ - return dma_map_sg_attrs(to_vmd_dev(dev), sg, nents, dir, attrs); -} - -static void vmd_unmap_sg(struct device *dev, struct scatterlist *sg, int nents, - enum dma_data_direction dir, unsigned long attrs) -{ - dma_unmap_sg_attrs(to_vmd_dev(dev), sg, nents, dir, attrs); -} - -static void vmd_sync_single_for_cpu(struct device *dev, dma_addr_t addr, - size_t size, enum dma_data_direction dir) -{ - dma_sync_single_for_cpu(to_vmd_dev(dev), addr, size, dir); -} - -static void vmd_sync_single_for_device(struct device *dev, dma_addr_t addr, - size_t size, enum dma_data_direction dir) -{ - dma_sync_single_for_device(to_vmd_dev(dev), addr, size, dir); -} - -static void vmd_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, - int nents, enum dma_data_direction dir) -{ - dma_sync_sg_for_cpu(to_vmd_dev(dev), sg, nents, dir); -} - -static void vmd_sync_sg_for_device(struct device *dev, struct scatterlist *sg, - int nents, enum dma_data_direction dir) -{ - dma_sync_sg_for_device(to_vmd_dev(dev), sg, nents, dir); -} - -static int vmd_dma_supported(struct device *dev, u64 mask) -{ - return dma_supported(to_vmd_dev(dev), mask); -} - -static u64 vmd_get_required_mask(struct device *dev) -{ - return dma_get_required_mask(to_vmd_dev(dev)); -} - -static void vmd_teardown_dma_ops(struct vmd_dev *vmd) -{ - struct dma_domain *domain = &vmd->dma_domain; - - if (get_dma_ops(&vmd->dev->dev)) - del_dma_domain(domain); -} - -#define ASSIGN_VMD_DMA_OPS(source, dest, fn) \ - do { \ - if (source->fn) \ - dest->fn = vmd_##fn; \ - } while (0) - -static void vmd_setup_dma_ops(struct vmd_dev *vmd) -{ - const struct dma_map_ops *source = get_dma_ops(&vmd->dev->dev); - struct dma_map_ops *dest = &vmd->dma_ops; - struct dma_domain *domain = &vmd->dma_domain; - - domain->domain_nr = vmd->sysdata.domain; - domain->dma_ops = dest; - - if (!source) - return; - ASSIGN_VMD_DMA_OPS(source, dest, alloc); - ASSIGN_VMD_DMA_OPS(source, dest, free); - ASSIGN_VMD_DMA_OPS(source, dest, mmap); - ASSIGN_VMD_DMA_OPS(source, dest, get_sgtable); - ASSIGN_VMD_DMA_OPS(source, dest, map_page); - ASSIGN_VMD_DMA_OPS(source, dest, unmap_page); - ASSIGN_VMD_DMA_OPS(source, dest, map_sg); - ASSIGN_VMD_DMA_OPS(source, dest, unmap_sg); - ASSIGN_VMD_DMA_OPS(source, dest, sync_single_for_cpu); - ASSIGN_VMD_DMA_OPS(source, dest, sync_single_for_device); - ASSIGN_VMD_DMA_OPS(source, dest, sync_sg_for_cpu); - ASSIGN_VMD_DMA_OPS(source, dest, sync_sg_for_device); - ASSIGN_VMD_DMA_OPS(source, dest, dma_supported); - ASSIGN_VMD_DMA_OPS(source, dest, get_required_mask); - add_dma_domain(domain); -} -#undef ASSIGN_VMD_DMA_OPS - static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus, unsigned int devfn, int reg, int len) { @@ -709,7 +561,6 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) } vmd_attach_resources(vmd); - vmd_setup_dma_ops(vmd); dev_set_msi_domain(&vmd->bus->dev, vmd->irq_domain); pci_scan_child_bus(vmd->bus); @@ -824,7 +675,6 @@ static void vmd_remove(struct pci_dev *dev) pci_stop_root_bus(vmd->bus); pci_remove_root_bus(vmd->bus); vmd_cleanup_srcu(vmd); - vmd_teardown_dma_ops(vmd); vmd_detach_resources(vmd); irq_domain_remove(vmd->irq_domain); } diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index ad746d9..ef7f219 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -6034,7 +6034,9 @@ bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2) return (dev1->dma_alias_mask && test_bit(dev2->devfn, dev1->dma_alias_mask)) || (dev2->dma_alias_mask && - test_bit(dev1->devfn, dev2->dma_alias_mask)); + test_bit(dev1->devfn, dev2->dma_alias_mask)) || + (dev1->dma_parent && dev1->dma_parent == dev2) || + (dev2->dma_parent && dev2->dma_parent == dev1); } bool pci_device_is_present(struct pci_dev *pdev) diff --git a/drivers/pci/search.c b/drivers/pci/search.c index bade140..a1d4899 100644 --- a/drivers/pci/search.c +++ b/drivers/pci/search.c @@ -32,6 +32,12 @@ int pci_for_each_dma_alias(struct pci_dev *pdev, struct pci_bus *bus; int ret; + if (unlikely(pdev->dma_parent)) { + pdev = pdev->dma_parent; + return fn(pdev, PCI_DEVID(pdev->bus->number, pdev->devfn), + data); + } + ret = fn(pdev, pci_dev_id(pdev), data); if (ret) return ret; diff --git a/include/linux/pci.h b/include/linux/pci.h index c393dff..0a10d1e 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -316,6 +316,7 @@ struct pci_dev { u8 pin; /* Interrupt pin this device uses */ u16 pcie_flags_reg; /* Cached PCIe Capabilities Register */ unsigned long *dma_alias_mask;/* Mask of enabled devfn aliases */ + struct pci_dev *dma_parent; /* DMA requester on another bus */ struct pci_driver *driver; /* Driver bound to this device */ u64 dma_mask; /* Mask of the bits of bus address this -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops 2019-12-31 20:24 ` [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops Jon Derrick @ 2020-01-09 14:36 ` Christoph Hellwig 2020-01-09 15:08 ` Derrick, Jonathan 0 siblings, 1 reply; 19+ messages in thread From: Christoph Hellwig @ 2020-01-09 14:36 UTC (permalink / raw) To: Jon Derrick Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On Tue, Dec 31, 2019 at 01:24:22PM -0700, Jon Derrick wrote: > Devices on the VMD domain use the VMD endpoint's requester-id and have > been relying on the VMD endpoint's dma operations. The downside of this > was that VMD domain devices would use the VMD endpoint's attributes when > doing DMA and IOMMU mapping. We can be smarter about this by only using > the VMD endpoint when mapping and providing the correct child device's > attributes during dma operations. > > This patch adds a new dma alias mechanism by adding a hint to a pci_dev > to point to a singular DMA requester's pci_dev. This integrates into the > existing dma alias infrastructure to reduce the impact of the changes > required to support this mode. If we want to lift this check into common code I think it should go into struct device, as that is what DMA operates on normally. That being said given that this insane hack only exists for braindamage in Intel hardware I'd rather keep it as isolated as possible. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops 2020-01-09 14:36 ` Christoph Hellwig @ 2020-01-09 15:08 ` Derrick, Jonathan 0 siblings, 0 replies; 19+ messages in thread From: Derrick, Jonathan @ 2020-01-09 15:08 UTC (permalink / raw) To: hch; +Cc: linux-pci, iommu, helgaas, kbusch, dwmw2 On Thu, 2020-01-09 at 15:36 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:22PM -0700, Jon Derrick wrote: > > Devices on the VMD domain use the VMD endpoint's requester-id and have > > been relying on the VMD endpoint's dma operations. The downside of this > > was that VMD domain devices would use the VMD endpoint's attributes when > > doing DMA and IOMMU mapping. We can be smarter about this by only using > > the VMD endpoint when mapping and providing the correct child device's > > attributes during dma operations. > > > > This patch adds a new dma alias mechanism by adding a hint to a pci_dev > > to point to a singular DMA requester's pci_dev. This integrates into the > > existing dma alias infrastructure to reduce the impact of the changes > > required to support this mode. > > If we want to lift this check into common code I think it should go > into struct device, as that is what DMA operates on normally. I thought about that too, but the dma alias mechanism was in pci_dev. I can prepare a new version with struct device. > That > being said given that this insane hack only exists for braindamage in > Intel hardware I'd rather keep it as isolated as possible. jmho but the footprint of the new set is pretty minimal and removes a lot of dubious code in vmd.c. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS 2019-12-31 20:24 [RFC 0/5] Clean up VMD DMA Map Ops Jon Derrick ` (3 preceding siblings ...) 2019-12-31 20:24 ` [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops Jon Derrick @ 2019-12-31 20:24 ` Jon Derrick 2020-01-09 14:37 ` Christoph Hellwig 2020-01-07 13:41 ` [RFC 0/5] Clean up VMD DMA Map Ops Joerg Roedel 5 siblings, 1 reply; 19+ messages in thread From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw) To: iommu, linux-pci Cc: Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig, Jon Derrick VMD was the only user of device dma operations. Now that the IOMMU has been made aware of direct DMA aliases, VMD domain devices can reference the VMD endpoint directly and the VMD device dma operations has been made obsolete. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> --- arch/x86/Kconfig | 3 --- arch/x86/include/asm/device.h | 10 ---------- arch/x86/pci/common.c | 38 -------------------------------------- 3 files changed, 51 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5e89499..77f9426 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2955,9 +2955,6 @@ config HAVE_ATOMIC_IOMAP def_bool y depends on X86_32 -config X86_DEV_DMA_OPS - bool - source "drivers/firmware/Kconfig" source "arch/x86/kvm/Kconfig" diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h index 5e12c63..7e31f7f 100644 --- a/arch/x86/include/asm/device.h +++ b/arch/x86/include/asm/device.h @@ -8,16 +8,6 @@ struct dev_archdata { #endif }; -#if defined(CONFIG_X86_DEV_DMA_OPS) && defined(CONFIG_PCI_DOMAINS) -struct dma_domain { - struct list_head node; - const struct dma_map_ops *dma_ops; - int domain_nr; -}; -void add_dma_domain(struct dma_domain *domain); -void del_dma_domain(struct dma_domain *domain); -#endif - struct pdev_archdata { }; diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c index 4022609..fcf03da 100644 --- a/arch/x86/pci/common.c +++ b/arch/x86/pci/common.c @@ -625,43 +625,6 @@ unsigned int pcibios_assign_all_busses(void) return (pci_probe & PCI_ASSIGN_ALL_BUSSES) ? 1 : 0; } -#if defined(CONFIG_X86_DEV_DMA_OPS) && defined(CONFIG_PCI_DOMAINS) -static LIST_HEAD(dma_domain_list); -static DEFINE_SPINLOCK(dma_domain_list_lock); - -void add_dma_domain(struct dma_domain *domain) -{ - spin_lock(&dma_domain_list_lock); - list_add(&domain->node, &dma_domain_list); - spin_unlock(&dma_domain_list_lock); -} -EXPORT_SYMBOL_GPL(add_dma_domain); - -void del_dma_domain(struct dma_domain *domain) -{ - spin_lock(&dma_domain_list_lock); - list_del(&domain->node); - spin_unlock(&dma_domain_list_lock); -} -EXPORT_SYMBOL_GPL(del_dma_domain); - -static void set_dma_domain_ops(struct pci_dev *pdev) -{ - struct dma_domain *domain; - - spin_lock(&dma_domain_list_lock); - list_for_each_entry(domain, &dma_domain_list, node) { - if (pci_domain_nr(pdev->bus) == domain->domain_nr) { - pdev->dev.dma_ops = domain->dma_ops; - break; - } - } - spin_unlock(&dma_domain_list_lock); -} -#else -static void set_dma_domain_ops(struct pci_dev *pdev) {} -#endif - static void set_dev_domain_options(struct pci_dev *pdev) { if (is_vmd(pdev->bus)) { @@ -701,7 +664,6 @@ int pcibios_add_device(struct pci_dev *dev) pa_data = data->next; memunmap(data); } - set_dma_domain_ops(dev); set_dev_domain_options(dev); return 0; } -- 1.8.3.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS 2019-12-31 20:24 ` [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS Jon Derrick @ 2020-01-09 14:37 ` Christoph Hellwig 2020-01-09 15:06 ` Derrick, Jonathan 0 siblings, 1 reply; 19+ messages in thread From: Christoph Hellwig @ 2020-01-09 14:37 UTC (permalink / raw) To: Jon Derrick Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On Tue, Dec 31, 2019 at 01:24:23PM -0700, Jon Derrick wrote: > VMD was the only user of device dma operations. Now that the IOMMU has > been made aware of direct DMA aliases, VMD domain devices can reference > the VMD endpoint directly and the VMD device dma operations has been > made obsolete. > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> This seems to be a 1:1 copy of my patch from August? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS 2020-01-09 14:37 ` Christoph Hellwig @ 2020-01-09 15:06 ` Derrick, Jonathan 0 siblings, 0 replies; 19+ messages in thread From: Derrick, Jonathan @ 2020-01-09 15:06 UTC (permalink / raw) To: hch; +Cc: linux-pci, iommu, helgaas, kbusch, dwmw2 On Thu, 2020-01-09 at 15:37 +0100, Christoph Hellwig wrote: > On Tue, Dec 31, 2019 at 01:24:23PM -0700, Jon Derrick wrote: > > VMD was the only user of device dma operations. Now that the IOMMU has > > been made aware of direct DMA aliases, VMD domain devices can reference > > the VMD endpoint directly and the VMD device dma operations has been > > made obsolete. > > > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> > > This seems to be a 1:1 copy of my patch from August? Sorry I didn't notice that. I'll give you attributions. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 0/5] Clean up VMD DMA Map Ops 2019-12-31 20:24 [RFC 0/5] Clean up VMD DMA Map Ops Jon Derrick ` (4 preceding siblings ...) 2019-12-31 20:24 ` [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS Jon Derrick @ 2020-01-07 13:41 ` Joerg Roedel 5 siblings, 0 replies; 19+ messages in thread From: Joerg Roedel @ 2020-01-07 13:41 UTC (permalink / raw) To: Jon Derrick Cc: linux-pci, iommu, Bjorn Helgaas, Keith Busch, David Woodhouse, Christoph Hellwig On Tue, Dec 31, 2019 at 01:24:18PM -0700, Jon Derrick wrote: > Jon Derrick (5): > iommu: Remove device link to group on failure > iommu/vt-d: Unlink device if failed to add to group Added 'Fixes:' tags to these two and applied them for v5.5, thanks. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2020-01-14 1:59 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-31 20:24 [RFC 0/5] Clean up VMD DMA Map Ops Jon Derrick 2019-12-31 20:24 ` [RFC 1/5] iommu: Remove device link to group on failure Jon Derrick 2020-01-01 3:59 ` Lu Baolu 2019-12-31 20:24 ` [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group Jon Derrick 2020-01-01 4:05 ` Lu Baolu 2020-01-12 1:36 ` Lu Baolu 2020-01-13 12:20 ` Joerg Roedel 2020-01-14 1:58 ` Lu Baolu 2019-12-31 20:24 ` [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata Jon Derrick 2020-01-09 14:33 ` Christoph Hellwig 2020-01-09 15:06 ` Derrick, Jonathan 2020-01-09 16:45 ` Derrick, Jonathan 2019-12-31 20:24 ` [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops Jon Derrick 2020-01-09 14:36 ` Christoph Hellwig 2020-01-09 15:08 ` Derrick, Jonathan 2019-12-31 20:24 ` [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS Jon Derrick 2020-01-09 14:37 ` Christoph Hellwig 2020-01-09 15:06 ` Derrick, Jonathan 2020-01-07 13:41 ` [RFC 0/5] Clean up VMD DMA Map Ops Joerg Roedel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).