P2P for DMA-buf

P2P for DMA-buf

[Christian König]

This is the third and final part of my series to start supporting P2P with DMA-buf.

The implementation is straight forward, apart from a helper to aid constructing scatterlists without having struct pages we only add a new flag indicating that an DMA-buf importer can handle peer2peer.

The exporter can then check if P2P is general possible using the pci_p2pdma_distance_many() function and if necessary can also clear the flag.

The rest is an example how to implementing the necessary functionality into the amdgpu driver to setup scatterlists pointing to device memory.

Please review and comment,
Christian.


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Christian König]

This can be used by drivers to setup P2P DMA between device
memory which is not backed by struct pages.

The drivers of the involved devices are responsible for
setting up and tearing down DMA addresses as necessary
using dma_map_resource().

The page pointer is set to NULL and only the DMA address,
length and offset values are valid.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 include/linux/scatterlist.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 6eec50fb36c8..28a477bf0bdf 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -145,6 +145,29 @@ static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
 	sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
 }
 
+/**
+ * sg_set_dma_addr - Set sg entry to point at specified dma address
+ * @sg:		 SG entry
+ * @address:	 DMA address to set
+ * @len:	 Length of data
+ * @offset:	 Offset into page
+ *
+ * Description:
+ *   Use this function to set an sg entry to point to device resources mapped
+ *   using dma_map_resource(). The page pointer is set to NULL and only the DMA
+ *   address, length and offset values are valid.
+ *
+ **/
+static inline void sg_set_dma_addr(struct scatterlist *sg, dma_addr_t address,
+				   unsigned int len, unsigned int offset)
+{
+	sg_set_page(sg, NULL, len, offset);
+	sg->dma_address = address;
+#ifdef CONFIG_NEED_SG_DMA_LENGTH
+	sg->dma_length = len;
+#endif
+}
+
 /*
  * Loop over each sg element, following the pointer to a new list if necessary
  */
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/6] dma-buf: add peer2peer flag

[Christian König]

Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/dma-buf/dma-buf.c |  2 ++
 include/linux/dma-buf.h   | 10 ++++++++++
 2 files changed, 12 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f4ace9af2191..f9220928ec90 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -689,6 +689,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
 
 	attach->dev = dev;
 	attach->dmabuf = dmabuf;
+	if (importer_ops)
+		attach->peer2peer = importer_ops->allow_peer2peer;
 	attach->importer_ops = importer_ops;
 	attach->importer_priv = importer_priv;
 
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 1ade486fc2bb..82e0a4a64601 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -334,6 +334,14 @@ struct dma_buf {
  * Attachment operations implemented by the importer.
  */
 struct dma_buf_attach_ops {
+	/**
+	 * @allow_peer2peer:
+	 *
+	 * If this is set to true the importer must be able to handle peer
+	 * resources without struct pages.
+	 */
+	bool allow_peer2peer;
+
 	/**
 	 * @move_notify
 	 *
@@ -362,6 +370,7 @@ struct dma_buf_attach_ops {
  * @node: list of dma_buf_attachment, protected by dma_resv lock of the dmabuf.
  * @sgt: cached mapping.
  * @dir: direction of cached mapping.
+ * @peer2peer: true if the importer can handle peer resources without pages.
  * @priv: exporter specific attachment data.
  * @importer_ops: importer operations for this attachment, if provided
  * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held.
@@ -382,6 +391,7 @@ struct dma_buf_attachment {
 	struct list_head node;
 	struct sg_table *sgt;
 	enum dma_data_direction dir;
+	bool peer2peer;
 	const struct dma_buf_attach_ops *importer_ops;
 	void *importer_priv;
 	void *priv;
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/6] drm/amdgpu: note that we can handle peer2peer DMA-buf

[Christian König]

Importing should work out of the box.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index ffeb20f11c07..aef12ee2f1e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -514,6 +514,7 @@ amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
 }
 
 static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
+	.allow_peer2peer = true,
 	.move_notify = amdgpu_dma_buf_move_notify
 };
 
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

[Christian König]

Check if we can do peer2peer on the PCIe bus.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index aef12ee2f1e3..bbf67800c8a6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -38,6 +38,7 @@
 #include <drm/amdgpu_drm.h>
 #include <linux/dma-buf.h>
 #include <linux/dma-fence-array.h>
+#include <linux/pci-p2pdma.h>
 
 /**
  * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
@@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
 	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
 	int r;
 
+	if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0)
+		attach->peer2peer = false;
+
 	if (attach->dev->driver == adev->dev->driver)
 		return 0;
 
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/6] drm/amdgpu: add support for exporting VRAM using DMA-buf v2

[Christian König]

We should be able to do this now after checking all the prerequisites.

v2: fix entrie count in the sgt

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  | 56 ++++++++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h      | 12 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 97 ++++++++++++++++++++
 3 files changed, 151 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index bbf67800c8a6..43d8ed7dbd00 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -276,14 +276,21 @@ static struct sg_table *amdgpu_dma_buf_map(struct dma_buf_attachment *attach,
 	struct dma_buf *dma_buf = attach->dmabuf;
 	struct drm_gem_object *obj = dma_buf->priv;
 	struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
 	struct sg_table *sgt;
 	long r;
 
 	if (!bo->pin_count) {
-		/* move buffer into GTT */
+		/* move buffer into GTT or VRAM */
 		struct ttm_operation_ctx ctx = { false, false };
+		unsigned domains = AMDGPU_GEM_DOMAIN_GTT;
 
-		amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+		if (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM &&
+		    attach->peer2peer) {
+			bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
+			domains |= AMDGPU_GEM_DOMAIN_VRAM;
+		}
+		amdgpu_bo_placement_from_domain(bo, domains);
 		r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
 		if (r)
 			return ERR_PTR(r);
@@ -293,20 +300,34 @@ static struct sg_table *amdgpu_dma_buf_map(struct dma_buf_attachment *attach,
 		return ERR_PTR(-EBUSY);
 	}
 
-	sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
-	if (IS_ERR(sgt))
-		return sgt;
-
-	if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
-			      DMA_ATTR_SKIP_CPU_SYNC))
-		goto error_free;
+	switch (bo->tbo.mem.mem_type) {
+	case TTM_PL_TT:
+		sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages,
+					    bo->tbo.num_pages);
+		if (IS_ERR(sgt))
+			return sgt;
+
+		if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
+				      DMA_ATTR_SKIP_CPU_SYNC))
+			goto error_free;
+		break;
+
+	case TTM_PL_VRAM:
+		r = amdgpu_vram_mgr_alloc_sgt(adev, &bo->tbo.mem, attach->dev,
+					      dir, &sgt);
+		if (r)
+			return ERR_PTR(r);
+		break;
+	default:
+		return ERR_PTR(-EINVAL);
+	}
 
 	return sgt;
 
 error_free:
 	sg_free_table(sgt);
 	kfree(sgt);
-	return ERR_PTR(-ENOMEM);
+	return ERR_PTR(-EBUSY);
 }
 
 /**
@@ -322,9 +343,18 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment *attach,
 				 struct sg_table *sgt,
 				 enum dma_data_direction dir)
 {
-	dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
-	sg_free_table(sgt);
-	kfree(sgt);
+	struct dma_buf *dma_buf = attach->dmabuf;
+	struct drm_gem_object *obj = dma_buf->priv;
+	struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+
+	if (sgt->sgl->page_link) {
+		dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+		sg_free_table(sgt);
+		kfree(sgt);
+	} else {
+		amdgpu_vram_mgr_free_sgt(adev, attach->dev, dir, sgt);
+	}
 }
 
 /**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 7551f3729445..a99d813b23a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -24,8 +24,9 @@
 #ifndef __AMDGPU_TTM_H__
 #define __AMDGPU_TTM_H__
 
-#include "amdgpu.h"
+#include <linux/dma-direction.h>
 #include <drm/gpu_scheduler.h>
+#include "amdgpu.h"
 
 #define AMDGPU_PL_GDS		(TTM_PL_PRIV + 0)
 #define AMDGPU_PL_GWS		(TTM_PL_PRIV + 1)
@@ -74,6 +75,15 @@ uint64_t amdgpu_gtt_mgr_usage(struct ttm_mem_type_manager *man);
 int amdgpu_gtt_mgr_recover(struct ttm_mem_type_manager *man);
 
 u64 amdgpu_vram_mgr_bo_visible_size(struct amdgpu_bo *bo);
+int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
+			      struct ttm_mem_reg *mem,
+			      struct device *dev,
+			      enum dma_data_direction dir,
+			      struct sg_table **sgt);
+void amdgpu_vram_mgr_free_sgt(struct amdgpu_device *adev,
+			      struct device *dev,
+			      enum dma_data_direction dir,
+			      struct sg_table *sgt);
 uint64_t amdgpu_vram_mgr_usage(struct ttm_mem_type_manager *man);
 uint64_t amdgpu_vram_mgr_vis_usage(struct ttm_mem_type_manager *man);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 82a3299e53c0..c6e7f00c5b21 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -22,6 +22,7 @@
  * Authors: Christian König
  */
 
+#include <linux/dma-mapping.h>
 #include "amdgpu.h"
 #include "amdgpu_vm.h"
 #include "amdgpu_atomfirmware.h"
@@ -458,6 +459,102 @@ static void amdgpu_vram_mgr_del(struct ttm_mem_type_manager *man,
 	mem->mm_node = NULL;
 }
 
+/**
+ * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
+ *
+ * @adev: amdgpu device pointer
+ * @mem: TTM memory object
+ * @dev: the other device
+ * @dir: dma direction
+ * @sgt: resulting sg table
+ *
+ * Allocate and fill a sg table from a VRAM allocation.
+ */
+int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
+			      struct ttm_mem_reg *mem,
+			      struct device *dev,
+			      enum dma_data_direction dir,
+			      struct sg_table **sgt)
+{
+	struct drm_mm_node *node;
+	struct scatterlist *sg;
+	int num_entries = 0;
+	unsigned int pages;
+	int i, r;
+
+	*sgt = kmalloc(sizeof(*sg), GFP_KERNEL);
+	if (!*sgt)
+		return -ENOMEM;
+
+	for (pages = mem->num_pages, node = mem->mm_node;
+	     pages; pages -= node->size, ++node)
+		++num_entries;
+
+	r = sg_alloc_table(*sgt, num_entries, GFP_KERNEL);
+	if (r)
+		goto error_free;
+
+	for_each_sg((*sgt)->sgl, sg, num_entries, i)
+		sg->length = 0;
+
+	node = mem->mm_node;
+	for_each_sg((*sgt)->sgl, sg, num_entries, i) {
+		phys_addr_t phys = (node->start << PAGE_SHIFT) +
+			adev->gmc.aper_base;
+		size_t size = node->size << PAGE_SHIFT;
+		dma_addr_t addr;
+
+		++node;
+		addr = dma_map_resource(dev, phys, size, dir,
+					DMA_ATTR_SKIP_CPU_SYNC);
+		r = dma_mapping_error(dev, addr);
+		if (r)
+			goto error_unmap;
+
+		sg_set_dma_addr(sg, addr, size, 0);
+	}
+	return 0;
+
+error_unmap:
+	for_each_sg((*sgt)->sgl, sg, num_entries, i) {
+		if (!sg->length)
+			continue;
+
+		dma_unmap_resource(dev, sg->dma_address,
+				   sg->length, dir,
+				   DMA_ATTR_SKIP_CPU_SYNC);
+	}
+	sg_free_table(*sgt);
+
+error_free:
+	kfree(*sgt);
+	return r;
+}
+
+/**
+ * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
+ *
+ * @adev: amdgpu device pointer
+ * @sgt: sg table to free
+ *
+ * Free a previously allocate sg table.
+ */
+void amdgpu_vram_mgr_free_sgt(struct amdgpu_device *adev,
+			      struct device *dev,
+			      enum dma_data_direction dir,
+			      struct sg_table *sgt)
+{
+	struct scatterlist *sg;
+	int i;
+
+	for_each_sg(sgt->sgl, sg, sgt->nents, i)
+		dma_unmap_resource(dev, sg->dma_address,
+				   sg->length, dir,
+				   DMA_ATTR_SKIP_CPU_SYNC);
+	sg_free_table(sgt);
+	kfree(sgt);
+}
+
 /**
  * amdgpu_vram_mgr_usage - how many bytes are used in this domain
  *
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/6] drm/amdgpu: improve amdgpu_gem_info debugfs file

[Christian König]

Note if a buffer was imported using peer2peer.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 4277125a79ee..e42608115c99 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -29,6 +29,7 @@
 #include <linux/module.h>
 #include <linux/pagemap.h>
 #include <linux/pci.h>
+#include <linux/dma-buf.h>
 
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_debugfs.h>
@@ -854,7 +855,8 @@ static int amdgpu_debugfs_gem_bo_info(int id, void *ptr, void *data)
 	attachment = READ_ONCE(bo->tbo.base.import_attach);
 
 	if (attachment)
-		seq_printf(m, " imported from %p", dma_buf);
+		seq_printf(m, " imported from %p%s", dma_buf,
+			   attachment->peer2peer ? " P2P" : "");
 	else if (dma_buf)
 		seq_printf(m, " exported as %p", dma_buf);
 
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

[Jason Gunthorpe]

On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote:
> Check if we can do peer2peer on the PCIe bus.
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index aef12ee2f1e3..bbf67800c8a6 100644
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -38,6 +38,7 @@
>  #include <drm/amdgpu_drm.h>
>  #include <linux/dma-buf.h>
>  #include <linux/dma-fence-array.h>
> +#include <linux/pci-p2pdma.h>
>  
>  /**
>   * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
> @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
>  	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>  	int r;
>  
> +	if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0)
> +		attach->peer2peer = false;
> +

Are there other related patches than this series?

p2p dma mapping needs to be done in common code, in p2pdma.c - ie this
open coding is missing the bus_offset stuff, at least. 

I really do not want to see drivers open code this stuff.

We already have a p2pdma API for handling the struct page case, so I
suggest adding some new p2pdma API to handle this for non-struct page
cases.

ie some thing like:

int 'p2pdma map bar'(
   struct pci_device *source,
   unsigned int source_bar_number, 
   struct pci_device *dest, 
   physaddr&len *array_of_offsets & length pairs into source bar,
   struct scatterlist *output_sgl)

Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

[Christian König]

Am 11.03.20 um 15:04 schrieb Jason Gunthorpe:
> On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote:
>> Check if we can do peer2peer on the PCIe bus.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>> index aef12ee2f1e3..bbf67800c8a6 100644
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>> @@ -38,6 +38,7 @@
>>   #include <drm/amdgpu_drm.h>
>>   #include <linux/dma-buf.h>
>>   #include <linux/dma-fence-array.h>
>> +#include <linux/pci-p2pdma.h>
>>   
>>   /**
>>    * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
>> @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
>>   	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>>   	int r;
>>   
>> +	if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0)
>> +		attach->peer2peer = false;
>> +
> Are there other related patches than this series?
>
> p2p dma mapping needs to be done in common code, in p2pdma.c - ie this
> open coding is missing the bus_offset stuff, at least.

Yeah, I'm aware of this. But I couldn't find a better way for now.

> I really do not want to see drivers open code this stuff.
>
> We already have a p2pdma API for handling the struct page case, so I
> suggest adding some new p2pdma API to handle this for non-struct page
> cases.
>
> ie some thing like:
>
> int 'p2pdma map bar'(
>     struct pci_device *source,
>     unsigned int source_bar_number,
>     struct pci_device *dest,
>     physaddr&len *array_of_offsets & length pairs into source bar,
>     struct scatterlist *output_sgl)

Well that's exactly what I have to avoid since I don't have the array of 
offsets around and want to avoid constructing it.

Similar problem for dma_map_resource(). My example does this on demand, 
but essentially we also have use cases where this is done only once.

Ideally we would have some function to create an sgl based on some 
arbitrary collection of offsets and length inside a BAR.

Regards,
Christian.

>
> Jason

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/6] drm/amdgpu: add support for exporting VRAM using DMA-buf v2

[Jason Gunthorpe]

On Wed, Mar 11, 2020 at 02:51:57PM +0100, Christian König wrote:
> +/**
> + * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
> + *
> + * @adev: amdgpu device pointer
> + * @mem: TTM memory object
> + * @dev: the other device
> + * @dir: dma direction
> + * @sgt: resulting sg table
> + *
> + * Allocate and fill a sg table from a VRAM allocation.
> + */
> +int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
> +			      struct ttm_mem_reg *mem,
> +			      struct device *dev,
> +			      enum dma_data_direction dir,
> +			      struct sg_table **sgt)

single ** pointer with an int return is odd, use ERR_PTR?

> +{
> +	struct drm_mm_node *node;
> +	struct scatterlist *sg;
> +	int num_entries = 0;
> +	unsigned int pages;
> +	int i, r;
> +
> +	*sgt = kmalloc(sizeof(*sg), GFP_KERNEL);
> +	if (!*sgt)
> +		return -ENOMEM;
> +
> +	for (pages = mem->num_pages, node = mem->mm_node;
> +	     pages; pages -= node->size, ++node)
> +		++num_entries;
> +
> +	r = sg_alloc_table(*sgt, num_entries, GFP_KERNEL);
> +	if (r)
> +		goto error_free;
> +
> +	for_each_sg((*sgt)->sgl, sg, num_entries, i)
> +		sg->length = 0;
> +
> +	node = mem->mm_node;
> +	for_each_sg((*sgt)->sgl, sg, num_entries, i) {
> +		phys_addr_t phys = (node->start << PAGE_SHIFT) +
> +			adev->gmc.aper_base;
> +		size_t size = node->size << PAGE_SHIFT;
> +		dma_addr_t addr;
> +
> +		++node;
> +		addr = dma_map_resource(dev, phys, size, dir,
> +					DMA_ATTR_SKIP_CPU_SYNC);
> +		r = dma_mapping_error(dev, addr);
> +		if (r)
> +			goto error_unmap;
> +
> +		sg_set_dma_addr(sg, addr, size, 0);

Is it possible that phys will need to have contiguous pages joined
here, or has 'node' already ensured contiguous pages?

Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

[Jason Gunthorpe]

On Wed, Mar 11, 2020 at 03:33:01PM +0100, Christian König wrote:
> Am 11.03.20 um 15:04 schrieb Jason Gunthorpe:
> > On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote:
> > > Check if we can do peer2peer on the PCIe bus.
> > > 
> > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++++
> > >   1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > index aef12ee2f1e3..bbf67800c8a6 100644
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > @@ -38,6 +38,7 @@
> > >   #include <drm/amdgpu_drm.h>
> > >   #include <linux/dma-buf.h>
> > >   #include <linux/dma-fence-array.h>
> > > +#include <linux/pci-p2pdma.h>
> > >   /**
> > >    * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
> > > @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
> > >   	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> > >   	int r;
> > > +	if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0)
> > > +		attach->peer2peer = false;
> > > +
> > Are there other related patches than this series?
> > 
> > p2p dma mapping needs to be done in common code, in p2pdma.c - ie this
> > open coding is missing the bus_offset stuff, at least.
> 
> Yeah, I'm aware of this. But I couldn't find a better way for now.

Well, it isn't optional :)
 
> > I really do not want to see drivers open code this stuff.
> > 
> > We already have a p2pdma API for handling the struct page case, so I
> > suggest adding some new p2pdma API to handle this for non-struct page
> > cases.
> > 
> > ie some thing like:
> > 
> > int 'p2pdma map bar'(
> >     struct pci_device *source,
> >     unsigned int source_bar_number,
> >     struct pci_device *dest,
> >     physaddr&len *array_of_offsets & length pairs into source bar,
> >     struct scatterlist *output_sgl)
> 
> Well that's exactly what I have to avoid since I don't have the array of
> offsets around and want to avoid constructing it.

Maybe it doesn't need an array of offsets - just a single offset and
callers can iterate the API?

> Similar problem for dma_map_resource(). My example does this on demand, but
> essentially we also have use cases where this is done only once.

I'm not sure if this is portable. Does any IOMMU HW need to know P2P
is happening to setup successfully? We currently support such a narrow
scope of HW for P2P..

> Ideally we would have some function to create an sgl based on some arbitrary
> collection of offsets and length inside a BAR.

Isn't that what I just proposed above ?

Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/6] drm/amdgpu: add support for exporting VRAM using DMA-buf v2

[Jason Gunthorpe]

On Wed, Mar 11, 2020 at 02:51:57PM +0100, Christian König wrote:

> +/**
> + * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
> + *
> + * @adev: amdgpu device pointer
> + * @sgt: sg table to free


Wrong kdoc in many ways

> + * Free a previously allocate sg table.
> + */
> +void amdgpu_vram_mgr_free_sgt(struct amdgpu_device *adev,
> +			      struct device *dev,
> +			      enum dma_data_direction dir,
> +			      struct sg_table *sgt)
> +{


Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

[Christian König]

Am 11.03.20 um 15:38 schrieb Jason Gunthorpe:
> On Wed, Mar 11, 2020 at 03:33:01PM +0100, Christian König wrote:
>> Am 11.03.20 um 15:04 schrieb Jason Gunthorpe:
>>> On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote:
>>>> Check if we can do peer2peer on the PCIe bus.
>>>>
>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>>    drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++++
>>>>    1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>>>> index aef12ee2f1e3..bbf67800c8a6 100644
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>>>> @@ -38,6 +38,7 @@
>>>>    #include <drm/amdgpu_drm.h>
>>>>    #include <linux/dma-buf.h>
>>>>    #include <linux/dma-fence-array.h>
>>>> +#include <linux/pci-p2pdma.h>
>>>>    /**
>>>>     * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
>>>> @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
>>>>    	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>>>>    	int r;
>>>> +	if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0)
>>>> +		attach->peer2peer = false;
>>>> +
>>> Are there other related patches than this series?
>>>
>>> p2p dma mapping needs to be done in common code, in p2pdma.c - ie this
>>> open coding is missing the bus_offset stuff, at least.
>> Yeah, I'm aware of this. But I couldn't find a better way for now.
> Well, it isn't optional :)
>   
>>> I really do not want to see drivers open code this stuff.
>>>
>>> We already have a p2pdma API for handling the struct page case, so I
>>> suggest adding some new p2pdma API to handle this for non-struct page
>>> cases.
>>>
>>> ie some thing like:
>>>
>>> int 'p2pdma map bar'(
>>>      struct pci_device *source,
>>>      unsigned int source_bar_number,
>>>      struct pci_device *dest,
>>>      physaddr&len *array_of_offsets & length pairs into source bar,
>>>      struct scatterlist *output_sgl)
>> Well that's exactly what I have to avoid since I don't have the array of
>> offsets around and want to avoid constructing it.
> Maybe it doesn't need an array of offsets - just a single offset and
> callers can iterate the API?

Yes, that would of course work as well.

But I was assuming that p2pdma_map_bar() needs some state between those 
calls.

>
>> Similar problem for dma_map_resource(). My example does this on demand, but
>> essentially we also have use cases where this is done only once.
> I'm not sure if this is portable. Does any IOMMU HW need to know P2P
> is happening to setup successfully? We currently support such a narrow
> scope of HW for P2P..

On the AMD hardware I'm testing this calling dma_map_resource() already 
seems to work with IOMMU enabled. (Well at least it seemed so 6month ago 
when I last tested this).

>> Ideally we would have some function to create an sgl based on some arbitrary
>> collection of offsets and length inside a BAR.
> Isn't that what I just proposed above ?

Yes, just didn't thought that this would easily possible. I will double 
check the p2pdma code again.

Thanks,
Christian.

>
> Jason

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

[Jason Gunthorpe]

On Wed, Mar 11, 2020 at 03:43:03PM +0100, Christian König wrote:
> > > > int 'p2pdma map bar'(
> > > >      struct pci_device *source,
> > > >      unsigned int source_bar_number,
> > > >      struct pci_device *dest,
> > > >      physaddr&len *array_of_offsets & length pairs into source bar,
> > > >      struct scatterlist *output_sgl)
> > > Well that's exactly what I have to avoid since I don't have the array of
> > > offsets around and want to avoid constructing it.
> > Maybe it doesn't need an array of offsets - just a single offset and
> > callers can iterate the API?
> 
> Yes, that would of course work as well.
> 
> But I was assuming that p2pdma_map_bar() needs some state between those
> calls.

It might be able to run faster if some state is held. We've had APIs
before where the caller can provide a cache for expensive state for
APIs. Maybe that would be an appropriate pattern here?

IIRC the distance calculation is the expensive bit, that would be easy
enough to cache.

Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/6] drm/amdgpu: add support for exporting VRAM using DMA-buf v2

[Alex Deucher]

On Wed, Mar 11, 2020 at 9:52 AM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> We should be able to do this now after checking all the prerequisites.
>
> v2: fix entrie count in the sgt
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  | 56 ++++++++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h      | 12 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 97 ++++++++++++++++++++
>  3 files changed, 151 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index bbf67800c8a6..43d8ed7dbd00 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -276,14 +276,21 @@ static struct sg_table *amdgpu_dma_buf_map(struct dma_buf_attachment *attach,
>         struct dma_buf *dma_buf = attach->dmabuf;
>         struct drm_gem_object *obj = dma_buf->priv;
>         struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> +       struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>         struct sg_table *sgt;
>         long r;
>
>         if (!bo->pin_count) {
> -               /* move buffer into GTT */
> +               /* move buffer into GTT or VRAM */
>                 struct ttm_operation_ctx ctx = { false, false };
> +               unsigned domains = AMDGPU_GEM_DOMAIN_GTT;
>
> -               amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
> +               if (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM &&
> +                   attach->peer2peer) {
> +                       bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
> +                       domains |= AMDGPU_GEM_DOMAIN_VRAM;
> +               }
> +               amdgpu_bo_placement_from_domain(bo, domains);
>                 r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
>                 if (r)
>                         return ERR_PTR(r);
> @@ -293,20 +300,34 @@ static struct sg_table *amdgpu_dma_buf_map(struct dma_buf_attachment *attach,
>                 return ERR_PTR(-EBUSY);
>         }
>
> -       sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
> -       if (IS_ERR(sgt))
> -               return sgt;
> -
> -       if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
> -                             DMA_ATTR_SKIP_CPU_SYNC))
> -               goto error_free;
> +       switch (bo->tbo.mem.mem_type) {
> +       case TTM_PL_TT:
> +               sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages,
> +                                           bo->tbo.num_pages);
> +               if (IS_ERR(sgt))
> +                       return sgt;
> +
> +               if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
> +                                     DMA_ATTR_SKIP_CPU_SYNC))
> +                       goto error_free;
> +               break;
> +
> +       case TTM_PL_VRAM:
> +               r = amdgpu_vram_mgr_alloc_sgt(adev, &bo->tbo.mem, attach->dev,
> +                                             dir, &sgt);
> +               if (r)
> +                       return ERR_PTR(r);
> +               break;
> +       default:
> +               return ERR_PTR(-EINVAL);
> +       }
>
>         return sgt;
>
>  error_free:
>         sg_free_table(sgt);
>         kfree(sgt);
> -       return ERR_PTR(-ENOMEM);
> +       return ERR_PTR(-EBUSY);
>  }
>
>  /**
> @@ -322,9 +343,18 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment *attach,
>                                  struct sg_table *sgt,
>                                  enum dma_data_direction dir)
>  {
> -       dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
> -       sg_free_table(sgt);
> -       kfree(sgt);
> +       struct dma_buf *dma_buf = attach->dmabuf;
> +       struct drm_gem_object *obj = dma_buf->priv;
> +       struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> +       struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> +
> +       if (sgt->sgl->page_link) {
> +               dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
> +               sg_free_table(sgt);
> +               kfree(sgt);
> +       } else {
> +               amdgpu_vram_mgr_free_sgt(adev, attach->dev, dir, sgt);
> +       }
>  }
>
>  /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> index 7551f3729445..a99d813b23a5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> @@ -24,8 +24,9 @@
>  #ifndef __AMDGPU_TTM_H__
>  #define __AMDGPU_TTM_H__
>
> -#include "amdgpu.h"
> +#include <linux/dma-direction.h>
>  #include <drm/gpu_scheduler.h>
> +#include "amdgpu.h"
>
>  #define AMDGPU_PL_GDS          (TTM_PL_PRIV + 0)
>  #define AMDGPU_PL_GWS          (TTM_PL_PRIV + 1)
> @@ -74,6 +75,15 @@ uint64_t amdgpu_gtt_mgr_usage(struct ttm_mem_type_manager *man);
>  int amdgpu_gtt_mgr_recover(struct ttm_mem_type_manager *man);
>
>  u64 amdgpu_vram_mgr_bo_visible_size(struct amdgpu_bo *bo);
> +int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
> +                             struct ttm_mem_reg *mem,
> +                             struct device *dev,
> +                             enum dma_data_direction dir,
> +                             struct sg_table **sgt);
> +void amdgpu_vram_mgr_free_sgt(struct amdgpu_device *adev,
> +                             struct device *dev,
> +                             enum dma_data_direction dir,
> +                             struct sg_table *sgt);
>  uint64_t amdgpu_vram_mgr_usage(struct ttm_mem_type_manager *man);
>  uint64_t amdgpu_vram_mgr_vis_usage(struct ttm_mem_type_manager *man);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index 82a3299e53c0..c6e7f00c5b21 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -22,6 +22,7 @@
>   * Authors: Christian König
>   */
>
> +#include <linux/dma-mapping.h>
>  #include "amdgpu.h"
>  #include "amdgpu_vm.h"
>  #include "amdgpu_atomfirmware.h"
> @@ -458,6 +459,102 @@ static void amdgpu_vram_mgr_del(struct ttm_mem_type_manager *man,
>         mem->mm_node = NULL;
>  }
>
> +/**
> + * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
> + *
> + * @adev: amdgpu device pointer
> + * @mem: TTM memory object
> + * @dev: the other device
> + * @dir: dma direction
> + * @sgt: resulting sg table
> + *
> + * Allocate and fill a sg table from a VRAM allocation.
> + */
> +int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
> +                             struct ttm_mem_reg *mem,
> +                             struct device *dev,
> +                             enum dma_data_direction dir,
> +                             struct sg_table **sgt)
> +{
> +       struct drm_mm_node *node;
> +       struct scatterlist *sg;
> +       int num_entries = 0;
> +       unsigned int pages;
> +       int i, r;
> +
> +       *sgt = kmalloc(sizeof(*sg), GFP_KERNEL);
> +       if (!*sgt)
> +               return -ENOMEM;
> +
> +       for (pages = mem->num_pages, node = mem->mm_node;
> +            pages; pages -= node->size, ++node)
> +               ++num_entries;
> +
> +       r = sg_alloc_table(*sgt, num_entries, GFP_KERNEL);
> +       if (r)
> +               goto error_free;
> +
> +       for_each_sg((*sgt)->sgl, sg, num_entries, i)
> +               sg->length = 0;
> +
> +       node = mem->mm_node;
> +       for_each_sg((*sgt)->sgl, sg, num_entries, i) {
> +               phys_addr_t phys = (node->start << PAGE_SHIFT) +
> +                       adev->gmc.aper_base;
> +               size_t size = node->size << PAGE_SHIFT;
> +               dma_addr_t addr;
> +
> +               ++node;
> +               addr = dma_map_resource(dev, phys, size, dir,
> +                                       DMA_ATTR_SKIP_CPU_SYNC);
> +               r = dma_mapping_error(dev, addr);
> +               if (r)
> +                       goto error_unmap;
> +
> +               sg_set_dma_addr(sg, addr, size, 0);
> +       }
> +       return 0;
> +
> +error_unmap:
> +       for_each_sg((*sgt)->sgl, sg, num_entries, i) {
> +               if (!sg->length)
> +                       continue;
> +
> +               dma_unmap_resource(dev, sg->dma_address,
> +                                  sg->length, dir,
> +                                  DMA_ATTR_SKIP_CPU_SYNC);
> +       }
> +       sg_free_table(*sgt);
> +
> +error_free:
> +       kfree(*sgt);
> +       return r;
> +}
> +
> +/**
> + * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table

This should be:
amdgpu_vram_mgr_free_sgt - unmap and free an sg table


> + *
> + * @adev: amdgpu device pointer
> + * @sgt: sg table to free
> + *
> + * Free a previously allocate sg table.
> + */
> +void amdgpu_vram_mgr_free_sgt(struct amdgpu_device *adev,
> +                             struct device *dev,
> +                             enum dma_data_direction dir,
> +                             struct sg_table *sgt)
> +{
> +       struct scatterlist *sg;
> +       int i;
> +
> +       for_each_sg(sgt->sgl, sg, sgt->nents, i)
> +               dma_unmap_resource(dev, sg->dma_address,
> +                                  sg->length, dir,
> +                                  DMA_ATTR_SKIP_CPU_SYNC);
> +       sg_free_table(sgt);
> +       kfree(sgt);
> +}
> +
>  /**
>   * amdgpu_vram_mgr_usage - how many bytes are used in this domain
>   *
> --
> 2.17.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Christian König]

Am 11.03.20 um 16:28 schrieb Christoph Hellwig:
> On Wed, Mar 11, 2020 at 02:51:53PM +0100, Christian König wrote:
>> This can be used by drivers to setup P2P DMA between device
>> memory which is not backed by struct pages.
>>
>> The drivers of the involved devices are responsible for
>> setting up and tearing down DMA addresses as necessary
>> using dma_map_resource().
>>
>> The page pointer is set to NULL and only the DMA address,
>> length and offset values are valid.
> NAK.  The only valid way to fill DMA address in scatterlists is
> dma_map_sg / dma_map_sg_attr.

How can we then map PCIe BARs into an scatterlist which are not backed 
by struct pages?

Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Christian König]

Am 12.03.20 um 11:19 schrieb Christoph Hellwig:
> On Thu, Mar 12, 2020 at 11:14:22AM +0100, Christian König wrote:
>>>> The page pointer is set to NULL and only the DMA address,
>>>> length and offset values are valid.
>>> NAK.  The only valid way to fill DMA address in scatterlists is
>>> dma_map_sg / dma_map_sg_attr.
>> How can we then map PCIe BARs into an scatterlist which are not backed by
>> struct pages?
> You can't.  scatterlists by definition map memory backed by a struct
> page.  If you want to map something else struct scatterlist is the
> wrong structure and you need to use something else (which you should
> anyway as struct scatterlist is a bad design patter, and the above
> is only one of the many issues with it).

But how should we then deal with all the existing interfaces which 
already take a scatterlist/sg_table ?

The whole DMA-buf design and a lot of drivers are build around 
scatterlist/sg_table and to me that actually makes quite a lot of sense.

For TTM I'm also trying for quite a while to just nuke the manual 
dma_address arrays we have and switch over to scatterlist/sg_table.

I mean we could come up with a new structure for this, but to me that 
just looks like reinventing the wheel. Especially since drivers need to 
be able to handle both I/O to system memory and I/O to PCIe BARs.

Regards,
Christian.


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Christian König]

Am 12.03.20 um 11:47 schrieb Christoph Hellwig:
> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote:
> [SNIP]
>> I mean we could come up with a new structure for this, but to me that just
>> looks like reinventing the wheel. Especially since drivers need to be able
>> to handle both I/O to system memory and I/O to PCIe BARs.
> The structure for holding the struct page side of the scatterlist is
> called struct bio_vec, so far mostly used by the block and networking
> code.

Yeah, I'm aware of this.

> The structure for holding dma addresses doesn't really exist
> in a generic form, but would be an array of these structures:
>
> struct dma_sg {
> 	dma_addr_t	addr;
> 	u32		len;
> };

So the whole idea is to nuke scatterlist/sg_table in the long term and 
switch over to using bio_vec as input and dma_sg as output for a DMA 
mapping operation.

Is that correct? If yes I could live with that, but it makes my patchset 
much more complicated.

> Keeping them separate is important as most IOMMU drivers will return
> less entries than you can feed them.  E.g. if your input boundaries
> are 4k aligned you will usually just get a single IOVA entry back.
> I will soon also have a dma mapping interface that will take advantage
> of that fact.

Yeah, I noticed as well that this is not really well handled.

Thanks for the feedback,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Jason Gunthorpe]

On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote:
> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote:
> > But how should we then deal with all the existing interfaces which already
> > take a scatterlist/sg_table ?
> >
> > The whole DMA-buf design and a lot of drivers are build around
> > scatterlist/sg_table and to me that actually makes quite a lot of sense.
> > 
> 
> Replace them with a saner interface that doesn't take a scatterlist.
> At very least for new functionality like peer to peer DMA, but
> especially this code would also benefit from a general move away
> from the scatterlist.

If dma buf can do P2P I'd like to see support for consuming a dmabuf
in RDMA. Looking at how.. there is an existing sgl based path starting
from get_user_pages through dma map to the drivers. (ib_umem)

I can replace the driver part with something else (dma_sg), but not
until we get a way to DMA map pages directly into that something
else..

The non-page scatterlist is also a big concern for RDMA as we have
drivers that want the page list, so even if we did as this series
contemplates I'd have still have to split the drivers and create the
notion of a dma-only SGL.

> > I mean we could come up with a new structure for this, but to me that just
> > looks like reinventing the wheel. Especially since drivers need to be able
> > to handle both I/O to system memory and I/O to PCIe BARs.
> 
> The structure for holding the struct page side of the scatterlist is
> called struct bio_vec, so far mostly used by the block and networking
> code.

I haven't used bio_vecs before, do they support chaining like SGL so
they can be very big? RDMA dma maps gigabytes of memory

> The structure for holding dma addresses doesn't really exist
> in a generic form, but would be an array of these structures:
> 
> struct dma_sg {
> 	dma_addr_t	addr;
> 	u32		len;
> };

Same question, RDMA needs to represent gigabytes of pages in a DMA
list, we will need some generic way to handle that. I suspect GPU has
a similar need? Can it be accomidated in some generic dma_sg?

So I'm guessing the path forward is something like

 - Add some generic dma_sg data structure and helper
 - Add dma mapping code to go from pages to dma_sg
 - Rework RDMA to use dma_sg and the new dma mapping code
 - Rework dmabuf to support dma mapping to a dma_sg
 - Rework GPU drivers to use dma_sg
 - Teach p2pdma to generate a dma_sg from a BAR page list
 - This series

?

Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Christian König]

Am 12.03.20 um 15:19 schrieb Jason Gunthorpe:
> On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote:
>> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote:
>>> But how should we then deal with all the existing interfaces which already
>>> take a scatterlist/sg_table ?
>>>
>>> The whole DMA-buf design and a lot of drivers are build around
>>> scatterlist/sg_table and to me that actually makes quite a lot of sense.
>>>
>> Replace them with a saner interface that doesn't take a scatterlist.
>> At very least for new functionality like peer to peer DMA, but
>> especially this code would also benefit from a general move away
>> from the scatterlist.
> If dma buf can do P2P I'd like to see support for consuming a dmabuf
> in RDMA.

That would indeed be awesome.

> Looking at how.. there is an existing sgl based path starting
> from get_user_pages through dma map to the drivers. (ib_umem)
>
> I can replace the driver part with something else (dma_sg), but not
> until we get a way to DMA map pages directly into that something
> else..
>
> The non-page scatterlist is also a big concern for RDMA as we have
> drivers that want the page list, so even if we did as this series
> contemplates I'd have still have to split the drivers and create the
> notion of a dma-only SGL.

Yeah that's my concern as well. For GPU drivers I don't think we need 
the struct pages anywhere, but that might not be true for others.

>>> I mean we could come up with a new structure for this, but to me that just
>>> looks like reinventing the wheel. Especially since drivers need to be able
>>> to handle both I/O to system memory and I/O to PCIe BARs.
>> The structure for holding the struct page side of the scatterlist is
>> called struct bio_vec, so far mostly used by the block and networking
>> code.
> I haven't used bio_vecs before, do they support chaining like SGL so
> they can be very big? RDMA dma maps gigabytes of memory
>
>> The structure for holding dma addresses doesn't really exist
>> in a generic form, but would be an array of these structures:
>>
>> struct dma_sg {
>> 	dma_addr_t	addr;
>> 	u32		len;
>> };
> Same question, RDMA needs to represent gigabytes of pages in a DMA
> list, we will need some generic way to handle that. I suspect GPU has
> a similar need? Can it be accomidated in some generic dma_sg?

Yes, we easily have ranges of >1GB. So I would certainly say u64 for the 
len here.

> So I'm guessing the path forward is something like
>
>   - Add some generic dma_sg data structure and helper
>   - Add dma mapping code to go from pages to dma_sg
>   - Rework RDMA to use dma_sg and the new dma mapping code
>   - Rework dmabuf to support dma mapping to a dma_sg
>   - Rework GPU drivers to use dma_sg
>   - Teach p2pdma to generate a dma_sg from a BAR page list
>   - This series
>
> ?

Sounds pretty much like a plan to me, but unfortunately like a rather 
huge one.

Because of this and cause I don't know if all drivers can live with 
dma_sg I'm not sure if we shouldn't have the switch from scatterlist to 
dma_sg separately to this peer2peer work.

Christian.

>
> Jason

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Logan Gunthorpe]

On 2020-03-12 8:19 a.m., Jason Gunthorpe wrote:
> On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote:
>> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote:
>>> But how should we then deal with all the existing interfaces which already
>>> take a scatterlist/sg_table ?
>>>
>>> The whole DMA-buf design and a lot of drivers are build around
>>> scatterlist/sg_table and to me that actually makes quite a lot of sense.
>>>
>>
>> Replace them with a saner interface that doesn't take a scatterlist.
>> At very least for new functionality like peer to peer DMA, but
>> especially this code would also benefit from a general move away
>> from the scatterlist.
> 
> If dma buf can do P2P I'd like to see support for consuming a dmabuf
> in RDMA. Looking at how.. there is an existing sgl based path starting
> from get_user_pages through dma map to the drivers. (ib_umem)
> 
> I can replace the driver part with something else (dma_sg), but not
> until we get a way to DMA map pages directly into that something
> else..
> 
> The non-page scatterlist is also a big concern for RDMA as we have
> drivers that want the page list, so even if we did as this series
> contemplates I'd have still have to split the drivers and create the
> notion of a dma-only SGL.
> 
>>> I mean we could come up with a new structure for this, but to me that just
>>> looks like reinventing the wheel. Especially since drivers need to be able
>>> to handle both I/O to system memory and I/O to PCIe BARs.
>>
>> The structure for holding the struct page side of the scatterlist is
>> called struct bio_vec, so far mostly used by the block and networking
>> code.
> 
> I haven't used bio_vecs before, do they support chaining like SGL so
> they can be very big? RDMA dma maps gigabytes of memory

bio_vec's themselves don't support chaining... In the block layer they
are used in a struct bio which handles chaining, splitting and other
features. Each bio, though, has a limit of 256 segments to avoid higher
order allocations. Depending on your use case, you could reuse bios or
write your own container to chain bio_vecs.

>> The structure for holding dma addresses doesn't really exist
>> in a generic form, but would be an array of these structures:
>>
>> struct dma_sg {
>> 	dma_addr_t	addr;
>> 	u32		len;
>> };


> Yes, we easily have ranges of >1GB. So I would certainly say u64 for the len here.

I'd probably avoid the u64 here and leave space for some flags or
something. If you have >1GB to map you can always just have mulitple
segments. With 4GB per segment and 256 segments per page, a page of DMA
sgs can easily map 1TB of memory in a single call and with chaining or
larger allocations you can extend that further, if needed.

Logan

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Jason Gunthorpe]

On Thu, Mar 12, 2020 at 04:39:02PM +0100, Christian König wrote:
> > > The structure for holding dma addresses doesn't really exist
> > > in a generic form, but would be an array of these structures:
> > > 
> > > struct dma_sg {
> > > 	dma_addr_t	addr;
> > > 	u32		len;
> > > };
> > Same question, RDMA needs to represent gigabytes of pages in a DMA
> > list, we will need some generic way to handle that. I suspect GPU has
> > a similar need? Can it be accomidated in some generic dma_sg?
> 
> Yes, we easily have ranges of >1GB. So I would certainly say u64 for the len
> here.

To be clear, I mean specifically 1GB of dma map composed of 262k
pages, mapped into 262k dma_sg's that take around some 4M of memory to
represent as struct dma_dg.

Really prefer some scheme that doesn't rely on vmalloc..

Some approach to have a single dma_sg > 4G seems less commonly needed?
I don't think any RDMA HW today can handle a single SGL that large at
least.

> >   - Add some generic dma_sg data structure and helper
> >   - Add dma mapping code to go from pages to dma_sg
> >   - Rework RDMA to use dma_sg and the new dma mapping code
> >   - Rework dmabuf to support dma mapping to a dma_sg
> >   - Rework GPU drivers to use dma_sg
> >   - Teach p2pdma to generate a dma_sg from a BAR page list
> >   - This series
> > 
> > ?
> 
> Sounds pretty much like a plan to me, but unfortunately like a rather huge
> one.

I know parts of this have been advancing.. CH has been working on
fixing up the DMA layer enough to do #1 and #2, I think.

> Because of this and cause I don't know if all drivers can live with dma_sg
> I'm not sure if we shouldn't have the switch from scatterlist to dma_sg
> separately to this peer2peer work.

So far any attempts to make sgls without struct page have failed for
various reasons. Too often obscure stuff does actually want the struct
page.

Stuffing BAR memory pages into the SGL is bad enough already. :(

One pragmatic path might be to define this new 'dma_sg' in a way where
it would have the same memory layout as a 'struct scatterlist'

Something like

struct dma_scatterlist {
        unsigned long   link;
        unsigned int    reserved1;
#ifndef CONFIG_NEED_SG_DMA_LENGTH
        unsigned int    dma_length;
#else
        unsigned int    reserved2;
#endif
        dma_addr_t      dma_address;
#ifdef CONFIG_NEED_SG_DMA_LENGTH
        unsigned int    dma_length;
#endif
};

struct dma_sg_table {
     union {
         struct dma_scatterlist *dma_sgl;
         struct future_more_efficient_structure *future;
     }
     unsigned int nents;
};

Then a dma_map_sg could be 

struct dma_sg_table *dma_map_sg_attrs_to_dma(
       struct device *dev, struct scatterlist *sg,
       int nents, enum dma_data_direction dir,
       unsigned long attrs)
{
   ret = dma_map_sg_attrs(dev, sg, nents, dir, attrs);
   res = kmalloc(sizeof(dma_sg_table));
   res->dma_sgl = sg;
   return res;
}

Then at least the work can get gets split up, I can switch RDMA
drivers to use dma_sg_table, then I can switch the subsystem to call
dma_map_sg_attrs_to_dma, then when we get dma_map_biovec_attrs() I can
work on switching the input sgl to a biovec without changing the
drivers.

After enough conversions are done we can optimize the memory layout
inside dma_sg_table, after everything is done we can drop support for
'dma_scatterlist'

It doesn't feel objectionable to build a 'dma_sg_table' without a
struct page.

Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Jason Gunthorpe]

On Fri, Mar 13, 2020 at 04:21:39AM -0700, Christoph Hellwig wrote:
> On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote:
> > The non-page scatterlist is also a big concern for RDMA as we have
> > drivers that want the page list, so even if we did as this series
> > contemplates I'd have still have to split the drivers and create the
> > notion of a dma-only SGL.
> 
> The drivers I looked at want a list of IOVA address, aligned to the
> device "page size".  What other data do drivers want?  Execept for the
> software protocol stack drivers, which of couse need pages for the
> stack futher down.

In principle it is possible to have just an aligned page list -
however the page size is variable, following certain rules, and today
the drivers still determine the correct page size largely on their
own.  

Some progress was made recently to consolidate this, but more is
needed.

If the common code doesn't know the device page size in advance then
today's approach of sending largest possible dma mapped SGLs into the
device driver is best. The driver only has to do splitting.

> > I haven't used bio_vecs before, do they support chaining like SGL so
> > they can be very big? RDMA dma maps gigabytes of memory
> 
> bio_vecs itself don't have the chaining, but the bios build around them
> do.  But each entry can map a huge pile.  If needed we could use the
> same chaining scheme we use for scatterlists for bio_vecs as well, but
> lets see if we really end up needing that.

RDMA surely needs something to generate huge lists of dma mapped
memory. MRs are very big objects

Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Christian König]

Am 13.03.20 um 12:21 schrieb Christoph Hellwig:
> On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote:
>> The non-page scatterlist is also a big concern for RDMA as we have
>> drivers that want the page list, so even if we did as this series
>> contemplates I'd have still have to split the drivers and create the
>> notion of a dma-only SGL.
> The drivers I looked at want a list of IOVA address, aligned to the
> device "page size".  What other data do drivers want?

Well for GPUs I have the requirement that those IOVA addresses allow 
random access.

That's the reason why we currently convert the sg_table into a linear 
arrays of addresses and pages. To solve that keeping the length in 
separate optional array would be ideal for us.

But this is so a special use case that I'm not sure if we want to 
support this in the common framework or not.

> Execept for the software protocol stack drivers, which of couse need pages for the
> stack futher down.

Yes completely agree.

For the GPUs I will propose a patch to stop copying the page from the 
sg_table over into our linear arrays and see if anybody starts to scream.

I don't think so, but probably better to double check.

Thanks,
Christian.

>
>> I haven't used bio_vecs before, do they support chaining like SGL so
>> they can be very big? RDMA dma maps gigabytes of memory
> bio_vecs itself don't have the chaining, but the bios build around them
> do.  But each entry can map a huge pile.  If needed we could use the
> same chaining scheme we use for scatterlists for bio_vecs as well, but
> lets see if we really end up needing that.
>
>> So I'm guessing the path forward is something like
>>
>>   - Add some generic dma_sg data structure and helper
>>   - Add dma mapping code to go from pages to dma_sg
> That has been on my todo list for a while.  All the DMA consolidatation
> is to prepare for that and we're finally getting close.

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Christian König]

Am 16.03.20 um 09:56 schrieb Christoph Hellwig:
> On Fri, Mar 13, 2020 at 09:17:42AM -0300, Jason Gunthorpe wrote:
>> On Fri, Mar 13, 2020 at 04:21:39AM -0700, Christoph Hellwig wrote:
>>> On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote:
>>>> The non-page scatterlist is also a big concern for RDMA as we have
>>>> drivers that want the page list, so even if we did as this series
>>>> contemplates I'd have still have to split the drivers and create the
>>>> notion of a dma-only SGL.
>>> The drivers I looked at want a list of IOVA address, aligned to the
>>> device "page size".  What other data do drivers want?  Execept for the
>>> software protocol stack drivers, which of couse need pages for the
>>> stack futher down.
>> In principle it is possible to have just an aligned page list -
>> however the page size is variable, following certain rules, and today
>> the drivers still determine the correct page size largely on their
>> own.
>>
>> Some progress was made recently to consolidate this, but more is
>> needed.
>>
>> If the common code doesn't know the device page size in advance then
>> today's approach of sending largest possible dma mapped SGLs into the
>> device driver is best. The driver only has to do splitting.
> The point was that drivers don't need pages, drivers need IOVAs.  In
> what form they are stuffed into the hardware is the drivers problem.

Well I would prefer if the drivers can somehow express their 
requirements and get IOVA structures already in the form they need.

Converting the IOVA data from one form to another is sometimes quite 
costly. Especially when it is only temporarily needed.

Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

[Jason Gunthorpe]

On Mon, Mar 16, 2020 at 02:52:13AM -0700, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 10:41:42AM +0100, Christian König wrote:
> > Well I would prefer if the drivers can somehow express their requirements
> > and get IOVA structures already in the form they need.
> > 
> > Converting the IOVA data from one form to another is sometimes quite costly.
> > Especially when it is only temporarily needed.
> 
> We basically have two ways to generate the IOVA:
> 
>   - a linear translation for the direct mapping case or some dumb IOMMU
>     drivers - in that case case there is a 1:1 mapping between input
>     segments and output segments in DMA mapping
>   - a non-trivial IOMMU where all aligned segments are merged into
>     a single IOVA range
> 
> So I don't really see how the dma layer could help much with any
> limitation beyond existing max size and dma boundary ones.

Christian are you thinking of something like the controllable
address&flags scheme in hmm_range_fault() so that the dma_map process
can write DMA address pages directly to some HW formatted structure?

Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel