All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC 0/5] Clean up VMD DMA Map Ops
@ 2019-12-31 20:24 ` Jon Derrick
  0 siblings, 0 replies; 40+ messages in thread
From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw)
  To: iommu, linux-pci
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel,
	Christoph Hellwig, David Woodhouse, Lu Baolu, 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


^ permalink raw reply	[flat|nested] 40+ messages in thread

* [RFC 0/5] Clean up VMD DMA Map Ops
@ 2019-12-31 20:24 ` Jon Derrick
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* [RFC 1/5] iommu: Remove device link to group on failure
  2019-12-31 20:24 ` Jon Derrick
@ 2019-12-31 20:24   ` Jon Derrick
  -1 siblings, 0 replies; 40+ messages in thread
From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw)
  To: iommu, linux-pci
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel,
	Christoph Hellwig, David Woodhouse, Lu Baolu, 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


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [RFC 1/5] iommu: Remove device link to group on failure
@ 2019-12-31 20:24   ` Jon Derrick
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group
  2019-12-31 20:24 ` Jon Derrick
@ 2019-12-31 20:24   ` Jon Derrick
  -1 siblings, 0 replies; 40+ messages in thread
From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw)
  To: iommu, linux-pci
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel,
	Christoph Hellwig, David Woodhouse, Lu Baolu, 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


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group
@ 2019-12-31 20:24   ` Jon Derrick
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata
  2019-12-31 20:24 ` Jon Derrick
@ 2019-12-31 20:24   ` Jon Derrick
  -1 siblings, 0 replies; 40+ messages in thread
From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw)
  To: iommu, linux-pci
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel,
	Christoph Hellwig, David Woodhouse, Lu Baolu, 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


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata
@ 2019-12-31 20:24   ` Jon Derrick
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops
  2019-12-31 20:24 ` Jon Derrick
@ 2019-12-31 20:24   ` Jon Derrick
  -1 siblings, 0 replies; 40+ messages in thread
From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw)
  To: iommu, linux-pci
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel,
	Christoph Hellwig, David Woodhouse, Lu Baolu, 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


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops
@ 2019-12-31 20:24   ` Jon Derrick
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS
  2019-12-31 20:24 ` Jon Derrick
@ 2019-12-31 20:24   ` Jon Derrick
  -1 siblings, 0 replies; 40+ messages in thread
From: Jon Derrick @ 2019-12-31 20:24 UTC (permalink / raw)
  To: iommu, linux-pci
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch, Joerg Roedel,
	Christoph Hellwig, David Woodhouse, Lu Baolu, 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


^ permalink raw reply related	[flat|nested] 40+ messages in thread

* [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS
@ 2019-12-31 20:24   ` Jon Derrick
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* Re: [RFC 1/5] iommu: Remove device link to group on failure
  2019-12-31 20:24   ` Jon Derrick
@ 2020-01-01  3:59     ` Lu Baolu
  -1 siblings, 0 replies; 40+ messages in thread
From: Lu Baolu @ 2020-01-01  3:59 UTC (permalink / raw)
  To: Jon Derrick, iommu, linux-pci
  Cc: baolu.lu, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch,
	Joerg Roedel, Christoph Hellwig, David Woodhouse

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:
> 

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 1/5] iommu: Remove device link to group on failure
@ 2020-01-01  3:59     ` Lu Baolu
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group
  2019-12-31 20:24   ` Jon Derrick
@ 2020-01-01  4:05     ` Lu Baolu
  -1 siblings, 0 replies; 40+ messages in thread
From: Lu Baolu @ 2020-01-01  4:05 UTC (permalink / raw)
  To: Jon Derrick, iommu, linux-pci
  Cc: baolu.lu, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch,
	Joerg Roedel, Christoph Hellwig, David Woodhouse

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)
> 

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group
@ 2020-01-01  4:05     ` Lu Baolu
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops
  2019-12-31 20:24   ` Jon Derrick
  (?)
@ 2020-01-03 15:00   ` kbuild test robot
  -1 siblings, 0 replies; 40+ messages in thread
From: kbuild test robot @ 2020-01-03 15:00 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 5222 bytes --]

Hi Jon,

[FYI, it's a private test report for your RFC patch.]
[auto build test ERROR on pci/next]
[also build test ERROR on iommu/next tip/x86/core v5.5-rc4 next-20191220]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Jon-Derrick/Clean-up-VMD-DMA-Map-Ops/20200103-175834
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-lkp (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from arch/x86/include/asm/percpu.h:45:0,
                    from arch/x86/include/asm/current.h:6,
                    from include/linux/sched.h:12,
                    from arch/x86/pci/common.c:8:
   arch/x86/pci/common.c: In function 'set_dev_domain_options':
>> arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/kernel.h:995:26: note: in definition of macro 'container_of'
     void *__mptr = (void *)(ptr);     \
                             ^~~
>> arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~
   In file included from arch/x86/include/asm/current.h:5:0,
                    from include/linux/sched.h:12,
                    from arch/x86/pci/common.c:8:
>> arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert'
      if (!(condition))     \
            ^~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
     ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
    #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                        ^~~~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
     ^~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:20: note: in expansion of macro '__same_type'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
                       ^~~~~~~~~~~
>> include/linux/pci.h:486:23: note: in expansion of macro 'container_of'
    #define to_pci_dev(n) container_of(n, struct pci_dev, dev)
                          ^~~~~~~~~~~~
>> arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~
>> arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert'
      if (!(condition))     \
            ^~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
     ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
    #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                        ^~~~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
     ^~~~~~~~~~~~~~~~
   include/linux/kernel.h:997:6: note: in expansion of macro '__same_type'
        !__same_type(*(ptr), void),   \
         ^~~~~~~~~~~
>> include/linux/pci.h:486:23: note: in expansion of macro 'container_of'
    #define to_pci_dev(n) container_of(n, struct pci_dev, dev)
                          ^~~~~~~~~~~~
>> arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~

vim +670 arch/x86/pci/common.c

   664	
   665	static void set_dev_domain_options(struct pci_dev *pdev)
   666	{
   667		if (is_vmd(pdev->bus)) {
   668			struct pci_sysdata *sd = pdev->bus->sysdata;
   669	
 > 670			pdev->dma_parent = to_pci_dev(sd->vmd_dev);
   671			pdev->hotplug_user_indicators = 1;
   672		}
   673	}
   674	

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 28801 bytes --]

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops
  2019-12-31 20:24   ` Jon Derrick
  (?)
  (?)
@ 2020-01-04  9:39   ` kbuild test robot
  -1 siblings, 0 replies; 40+ messages in thread
From: kbuild test robot @ 2020-01-04  9:39 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 14231 bytes --]

Hi Jon,

[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on pci/next]
[also build test WARNING on iommu/next tip/x86/core v5.5-rc4 next-20191220]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Jon-Derrick/Clean-up-VMD-DMA-Map-Ops/20200103-175834
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-randconfig-f001-20200103 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

   In file included from arch/x86/include/asm/percpu.h:45:0,
                    from arch/x86/include/asm/current.h:6,
                    from include/linux/sched.h:12,
                    from arch/x86/pci/common.c:8:
   arch/x86/pci/common.c: In function 'set_dev_domain_options':
   arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/kernel.h:995:26: note: in definition of macro 'container_of'
     void *__mptr = (void *)(ptr);     \
                             ^~~
   arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~
   In file included from arch/x86/include/asm/current.h:5:0,
                    from include/linux/sched.h:12,
                    from arch/x86/pci/common.c:8:
   arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
    #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
                                                       ^~~~
>> include/linux/compiler.h:330:3: note: in expansion of macro 'if'
      if (!(condition))     \
      ^~
   include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert'
     __compiletime_assert(condition, msg, prefix, suffix)
     ^~~~~~~~~~~~~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
     ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
    #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                        ^~~~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
     ^~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:20: note: in expansion of macro '__same_type'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
                       ^~~~~~~~~~~
   include/linux/pci.h:486:23: note: in expansion of macro 'container_of'
    #define to_pci_dev(n) container_of(n, struct pci_dev, dev)
                          ^~~~~~~~~~~~
   arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~
   arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
    #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
                                                       ^~~~
>> include/linux/compiler.h:330:3: note: in expansion of macro 'if'
      if (!(condition))     \
      ^~
   include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert'
     __compiletime_assert(condition, msg, prefix, suffix)
     ^~~~~~~~~~~~~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
     ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
    #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                        ^~~~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
     ^~~~~~~~~~~~~~~~
   include/linux/kernel.h:997:6: note: in expansion of macro '__same_type'
        !__same_type(*(ptr), void),   \
         ^~~~~~~~~~~
   include/linux/pci.h:486:23: note: in expansion of macro 'container_of'
    #define to_pci_dev(n) container_of(n, struct pci_dev, dev)
                          ^~~~~~~~~~~~
   arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~
   arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var'
    #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
                                                                ^~~~
>> include/linux/compiler.h:330:3: note: in expansion of macro 'if'
      if (!(condition))     \
      ^~
   include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert'
     __compiletime_assert(condition, msg, prefix, suffix)
     ^~~~~~~~~~~~~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
     ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
    #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                        ^~~~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
     ^~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:20: note: in expansion of macro '__same_type'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
                       ^~~~~~~~~~~
   include/linux/pci.h:486:23: note: in expansion of macro 'container_of'
    #define to_pci_dev(n) container_of(n, struct pci_dev, dev)
                          ^~~~~~~~~~~~
   arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~
   arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/compiler.h:58:61: note: in definition of macro '__trace_if_var'
    #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
                                                                ^~~~
>> include/linux/compiler.h:330:3: note: in expansion of macro 'if'
      if (!(condition))     \
      ^~
   include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert'
     __compiletime_assert(condition, msg, prefix, suffix)
     ^~~~~~~~~~~~~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
     ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
    #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                        ^~~~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
     ^~~~~~~~~~~~~~~~
   include/linux/kernel.h:997:6: note: in expansion of macro '__same_type'
        !__same_type(*(ptr), void),   \
         ^~~~~~~~~~~
   include/linux/pci.h:486:23: note: in expansion of macro 'container_of'
    #define to_pci_dev(n) container_of(n, struct pci_dev, dev)
                          ^~~~~~~~~~~~
   arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~
   arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/compiler.h:69:3: note: in definition of macro '__trace_if_value'
     (cond) ?     \
      ^~~~
   include/linux/compiler.h:56:28: note: in expansion of macro '__trace_if_var'
    #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
                               ^~~~~~~~~~~~~~
>> include/linux/compiler.h:330:3: note: in expansion of macro 'if'
      if (!(condition))     \
      ^~
   include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert'
     __compiletime_assert(condition, msg, prefix, suffix)
     ^~~~~~~~~~~~~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
     ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
    #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                        ^~~~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
     ^~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:20: note: in expansion of macro '__same_type'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
                       ^~~~~~~~~~~
   include/linux/pci.h:486:23: note: in expansion of macro 'container_of'
    #define to_pci_dev(n) container_of(n, struct pci_dev, dev)
                          ^~~~~~~~~~~~
   arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~
   arch/x86/pci/common.c:670:35: error: 'struct pci_sysdata' has no member named 'vmd_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                                      ^
   include/linux/compiler.h:69:3: note: in definition of macro '__trace_if_value'
     (cond) ?     \
      ^~~~
   include/linux/compiler.h:56:28: note: in expansion of macro '__trace_if_var'
    #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
                               ^~~~~~~~~~~~~~
>> include/linux/compiler.h:330:3: note: in expansion of macro 'if'
      if (!(condition))     \
      ^~
   include/linux/compiler.h:338:2: note: in expansion of macro '__compiletime_assert'
     __compiletime_assert(condition, msg, prefix, suffix)
     ^~~~~~~~~~~~~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
     ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
    #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                        ^~~~~~~~~~~~~~~~~~
   include/linux/kernel.h:996:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
     ^~~~~~~~~~~~~~~~
   include/linux/kernel.h:997:6: note: in expansion of macro '__same_type'
        !__same_type(*(ptr), void),   \
         ^~~~~~~~~~~
   include/linux/pci.h:486:23: note: in expansion of macro 'container_of'
    #define to_pci_dev(n) container_of(n, struct pci_dev, dev)
                          ^~~~~~~~~~~~
   arch/x86/pci/common.c:670:22: note: in expansion of macro 'to_pci_dev'
      pdev->dma_parent = to_pci_dev(sd->vmd_dev);
                         ^~~~~~~~~~

vim +/if +330 include/linux/compiler.h

c361d3e54364d1 Daniel Santos   2013-02-21  325  
c03567a8e8d5cf Joe Stringer    2017-08-31  326  #ifdef __OPTIMIZE__
9a8ab1c39970a4 Daniel Santos   2013-02-21  327  # define __compiletime_assert(condition, msg, prefix, suffix)		\
9a8ab1c39970a4 Daniel Santos   2013-02-21  328  	do {								\
9a8ab1c39970a4 Daniel Santos   2013-02-21  329  		extern void prefix ## suffix(void) __compiletime_error(msg); \
81b45683487a51 Masahiro Yamada 2018-08-26 @330  		if (!(condition))					\
9a8ab1c39970a4 Daniel Santos   2013-02-21  331  			prefix ## suffix();				\
9a8ab1c39970a4 Daniel Santos   2013-02-21  332  	} while (0)
c03567a8e8d5cf Joe Stringer    2017-08-31  333  #else
c03567a8e8d5cf Joe Stringer    2017-08-31  334  # define __compiletime_assert(condition, msg, prefix, suffix) do { } while (0)
c03567a8e8d5cf Joe Stringer    2017-08-31  335  #endif
9a8ab1c39970a4 Daniel Santos   2013-02-21  336  

:::::: The code at line 330 was first introduced by commit
:::::: 81b45683487a51b0f4d3b29d37f20d6d078544e4 compiler.h: give up __compiletime_assert_fallback()

:::::: TO: Masahiro Yamada <yamada.masahiro@socionext.com>
:::::: CC: Kees Cook <keescook@chromium.org>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 32604 bytes --]

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 0/5] Clean up VMD DMA Map Ops
  2019-12-31 20:24 ` Jon Derrick
@ 2020-01-07 13:41   ` Joerg Roedel
  -1 siblings, 0 replies; 40+ messages in thread
From: Joerg Roedel @ 2020-01-07 13:41 UTC (permalink / raw)
  To: Jon Derrick
  Cc: iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch,
	Christoph Hellwig, David Woodhouse, Lu Baolu

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.

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 0/5] Clean up VMD DMA Map Ops
@ 2020-01-07 13:41   ` Joerg Roedel
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata
  2019-12-31 20:24   ` Jon Derrick
@ 2020-01-09 14:33     ` Christoph Hellwig
  -1 siblings, 0 replies; 40+ messages in thread
From: Christoph Hellwig @ 2020-01-09 14:33 UTC (permalink / raw)
  To: Jon Derrick
  Cc: iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch,
	Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu

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?

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata
@ 2020-01-09 14:33     ` Christoph Hellwig
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops
  2019-12-31 20:24   ` Jon Derrick
@ 2020-01-09 14:36     ` Christoph Hellwig
  -1 siblings, 0 replies; 40+ messages in thread
From: Christoph Hellwig @ 2020-01-09 14:36 UTC (permalink / raw)
  To: Jon Derrick
  Cc: iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch,
	Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu

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.

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops
@ 2020-01-09 14:36     ` Christoph Hellwig
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* Re: [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS
  2019-12-31 20:24   ` Jon Derrick
@ 2020-01-09 14:37     ` Christoph Hellwig
  -1 siblings, 0 replies; 40+ messages in thread
From: Christoph Hellwig @ 2020-01-09 14:37 UTC (permalink / raw)
  To: Jon Derrick
  Cc: iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch,
	Joerg Roedel, Christoph Hellwig, David Woodhouse, Lu Baolu

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?

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS
@ 2020-01-09 14:37     ` Christoph Hellwig
  0 siblings, 0 replies; 40+ 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] 40+ 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
  -1 siblings, 0 replies; 40+ messages in thread
From: Derrick, Jonathan @ 2020-01-09 15:06 UTC (permalink / raw)
  To: hch
  Cc: lorenzo.pieralisi, baolu.lu, joro, iommu, helgaas, kbusch, dwmw2,
	linux-pci

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata
@ 2020-01-09 15:06       ` Derrick, Jonathan
  0 siblings, 0 replies; 40+ 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] 40+ 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
  -1 siblings, 0 replies; 40+ messages in thread
From: Derrick, Jonathan @ 2020-01-09 15:06 UTC (permalink / raw)
  To: hch
  Cc: lorenzo.pieralisi, baolu.lu, joro, iommu, helgaas, kbusch, dwmw2,
	linux-pci

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.

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 5/5] x86/PCI: Remove unused X86_DEV_DMA_OPS
@ 2020-01-09 15:06       ` Derrick, Jonathan
  0 siblings, 0 replies; 40+ 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] 40+ 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
  -1 siblings, 0 replies; 40+ messages in thread
From: Derrick, Jonathan @ 2020-01-09 15:08 UTC (permalink / raw)
  To: hch
  Cc: lorenzo.pieralisi, baolu.lu, joro, iommu, helgaas, kbusch, dwmw2,
	linux-pci

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.

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 4/5] PCI: vmd: Stop overriding dma_map_ops
@ 2020-01-09 15:08       ` Derrick, Jonathan
  0 siblings, 0 replies; 40+ 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] 40+ 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 16:45       ` Derrick, Jonathan
  -1 siblings, 0 replies; 40+ messages in thread
From: Derrick, Jonathan @ 2020-01-09 16:45 UTC (permalink / raw)
  To: hch
  Cc: lorenzo.pieralisi, baolu.lu, joro, iommu, helgaas, kbusch, dwmw2,
	linux-pci

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.

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 3/5] x86/PCI: Expose VMD's device in pci_sysdata
@ 2020-01-09 16:45       ` Derrick, Jonathan
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group
  2019-12-31 20:24   ` Jon Derrick
@ 2020-01-12  1:36     ` Lu Baolu
  -1 siblings, 0 replies; 40+ messages in thread
From: Lu Baolu @ 2020-01-12  1:36 UTC (permalink / raw)
  To: Jon Derrick, iommu, linux-pci
  Cc: baolu.lu, Bjorn Helgaas, Lorenzo Pieralisi, Keith Busch,
	Joerg Roedel, Christoph Hellwig, David Woodhouse

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

^ permalink raw reply	[flat|nested] 40+ 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
  0 siblings, 0 replies; 40+ 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] 40+ 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
  -1 siblings, 0 replies; 40+ messages in thread
From: Joerg Roedel @ 2020-01-13 12:20 UTC (permalink / raw)
  To: Lu Baolu
  Cc: Jon Derrick, iommu, linux-pci, Bjorn Helgaas, Lorenzo Pieralisi,
	Keith Busch, Christoph Hellwig, David Woodhouse

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


^ permalink raw reply	[flat|nested] 40+ 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
  0 siblings, 0 replies; 40+ 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] 40+ 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
  -1 siblings, 0 replies; 40+ messages in thread
From: Lu Baolu @ 2020-01-14  1:58 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: baolu.lu, Jon Derrick, iommu, linux-pci, Bjorn Helgaas,
	Lorenzo Pieralisi, Keith Busch, Christoph Hellwig,
	David Woodhouse

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

^ permalink raw reply	[flat|nested] 40+ messages in thread

* Re: [RFC 2/5] iommu/vt-d: Unlink device if failed to add to group
@ 2020-01-14  1:58         ` Lu Baolu
  0 siblings, 0 replies; 40+ 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] 40+ messages in thread

end of thread, other threads:[~2020-01-14  1:59 UTC | newest]

Thread overview: 40+ 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 ` 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  3:59   ` Lu Baolu
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
2019-12-31 20:24   ` Jon Derrick
2020-01-01  4:05   ` Lu Baolu
2020-01-01  4:05     ` Lu Baolu
2020-01-12  1:36   ` Lu Baolu
2020-01-12  1:36     ` Lu Baolu
2020-01-13 12:20     ` Joerg Roedel
2020-01-13 12:20       ` Joerg Roedel
2020-01-14  1:58       ` Lu Baolu
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
2019-12-31 20:24   ` Jon Derrick
2020-01-09 14:33   ` Christoph Hellwig
2020-01-09 14:33     ` Christoph Hellwig
2020-01-09 15:06     ` Derrick, Jonathan
2020-01-09 15:06       ` Derrick, Jonathan
2020-01-09 16:45     ` 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
2019-12-31 20:24   ` Jon Derrick
2020-01-03 15:00   ` kbuild test robot
2020-01-04  9:39   ` kbuild test robot
2020-01-09 14:36   ` Christoph Hellwig
2020-01-09 14:36     ` Christoph Hellwig
2020-01-09 15:08     ` Derrick, Jonathan
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
2019-12-31 20:24   ` Jon Derrick
2020-01-09 14:37   ` Christoph Hellwig
2020-01-09 14:37     ` Christoph Hellwig
2020-01-09 15:06     ` Derrick, Jonathan
2020-01-09 15:06       ` Derrick, Jonathan
2020-01-07 13:41 ` [RFC 0/5] Clean up VMD DMA Map Ops Joerg Roedel
2020-01-07 13:41   ` Joerg Roedel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.