[PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Christian König]

On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.

On the importer side we add an optional invalidate callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.

This allows the exporter to provide the mappings without the need to pin
the backing store.

v2: don't try to invalidate mappings when the callback is NULL,
    lock the reservation obj while using the attachments,
    add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
    use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
    everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
v11: drop automatically re-entry avoidance
v12: rename callback to move_notify

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

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6c15deb5d4ad..216f76109f3f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
 		return ERR_PTR(-EINVAL);
 	}
 
+	if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
+		return ERR_PTR(-EINVAL);
+
 	if (!try_module_get(exp_info->owner))
 		return ERR_PTR(-ENOENT);
 
@@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
 EXPORT_SYMBOL_GPL(dma_buf_put);
 
 /**
- * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
+ * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list; optionally,
  * calls attach() of dma_buf_ops to allow device-specific attach functionality
- * @dmabuf:	[in]	buffer to attach device to.
- * @dev:	[in]	device to be attached.
+ * @dmabuf:		[in]	buffer to attach device to.
+ * @dev:		[in]	device to be attached.
+ * @importer_ops	[in]	importer operations for the attachment
+ * @importer_priv	[in]	importer private pointer for the attachment
  *
  * Returns struct dma_buf_attachment pointer for this attachment. Attachments
  * must be cleaned up by calling dma_buf_detach().
@@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
  * accessible to @dev, and cannot be moved to a more suitable place. This is
  * indicated with the error code -EBUSY.
  */
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
-					  struct device *dev)
+struct dma_buf_attachment *
+dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
+		       const struct dma_buf_attach_ops *importer_ops,
+		       void *importer_priv)
 {
 	struct dma_buf_attachment *attach;
 	int ret;
@@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
 
 	attach->dev = dev;
 	attach->dmabuf = dmabuf;
+	attach->importer_ops = importer_ops;
+	attach->importer_priv = importer_priv;
 
 	mutex_lock(&dmabuf->lock);
 
@@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
 		if (ret)
 			goto err_attach;
 	}
+	reservation_object_lock(dmabuf->resv, NULL);
 	list_add(&attach->node, &dmabuf->attachments);
+	reservation_object_unlock(dmabuf->resv);
 
 	mutex_unlock(&dmabuf->lock);
 
+	/* When either the importer or the exporter can't handle dynamic
+	 * mappings we cache the mapping here to avoid issues with the
+	 * reservation object lock.
+	 */
+	if (dma_buf_attachment_is_dynamic(attach) !=
+	    dma_buf_is_dynamic(dmabuf)) {
+		struct sg_table *sgt;
+
+		if (dma_buf_is_dynamic(attach->dmabuf)) {
+			reservation_object_lock(attach->dmabuf->resv, NULL);
+			ret = dma_buf_pin(attach);
+			if (ret)
+				goto err_unlock;
+		}
+
+		sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
+		if (!sgt)
+			sgt = ERR_PTR(-ENOMEM);
+		if (IS_ERR(sgt)) {
+			ret = PTR_ERR(sgt);
+			goto err_unpin;
+		}
+		if (dma_buf_is_dynamic(attach->dmabuf))
+			reservation_object_unlock(attach->dmabuf->resv);
+		attach->sgt = sgt;
+		attach->dir = DMA_BIDIRECTIONAL;
+	}
+
 	return attach;
 
 err_attach:
 	kfree(attach);
 	mutex_unlock(&dmabuf->lock);
 	return ERR_PTR(ret);
+
+err_unpin:
+	if (dma_buf_is_dynamic(attach->dmabuf))
+		dma_buf_unpin(attach);
+
+err_unlock:
+	if (dma_buf_is_dynamic(attach->dmabuf))
+		reservation_object_unlock(attach->dmabuf->resv);
+
+	dma_buf_detach(dmabuf, attach);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
+
+/**
+ * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
+ * @dmabuf:	[in]	buffer to attach device to.
+ * @dev:	[in]	device to be attached.
+ *
+ * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a static
+ * mapping.
+ */
+struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
+					  struct device *dev)
+{
+	return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
 }
 EXPORT_SYMBOL_GPL(dma_buf_attach);
 
@@ -717,11 +782,22 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
 	if (WARN_ON(!dmabuf || !attach))
 		return;
 
-	if (attach->sgt)
+	if (attach->sgt) {
+		if (dma_buf_is_dynamic(attach->dmabuf))
+			reservation_object_lock(attach->dmabuf->resv, NULL);
+
 		dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir);
 
+		if (dma_buf_is_dynamic(attach->dmabuf)) {
+			dma_buf_unpin(attach);
+			reservation_object_unlock(attach->dmabuf->resv);
+		}
+	}
+
 	mutex_lock(&dmabuf->lock);
+	reservation_object_lock(dmabuf->resv, NULL);
 	list_del(&attach->node);
+	reservation_object_unlock(dmabuf->resv);
 	if (dmabuf->ops->detach)
 		dmabuf->ops->detach(dmabuf, attach);
 
@@ -730,6 +806,44 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
 }
 EXPORT_SYMBOL_GPL(dma_buf_detach);
 
+/**
+ * dma_buf_pin - Lock down the DMA-buf
+ *
+ * @attach:	[in]	attachment which should be pinned
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+int dma_buf_pin(struct dma_buf_attachment *attach)
+{
+	struct dma_buf *dmabuf = attach->dmabuf;
+	int ret = 0;
+
+	reservation_object_assert_held(dmabuf->resv);
+
+	if (dmabuf->ops->pin)
+		ret = dmabuf->ops->pin(attach);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dma_buf_pin);
+
+/**
+ * dma_buf_unpin - Remove lock from DMA-buf
+ *
+ * @attach:	[in]	attachment which should be unpinned
+ */
+void dma_buf_unpin(struct dma_buf_attachment *attach)
+{
+	struct dma_buf *dmabuf = attach->dmabuf;
+
+	reservation_object_assert_held(dmabuf->resv);
+
+	if (dmabuf->ops->unpin)
+		dmabuf->ops->unpin(attach);
+}
+EXPORT_SYMBOL_GPL(dma_buf_unpin);
+
 /**
  * dma_buf_map_attachment - Returns the scatterlist table of the attachment;
  * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
@@ -749,6 +863,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
 					enum dma_data_direction direction)
 {
 	struct sg_table *sg_table;
+	int r;
 
 	might_sleep();
 
@@ -767,10 +882,29 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
 		return attach->sgt;
 	}
 
+	if (dma_buf_attachment_is_dynamic(attach)) {
+		reservation_object_assert_held(attach->dmabuf->resv);
+
+	} else if (dma_buf_is_dynamic(attach->dmabuf)) {
+		reservation_object_lock(attach->dmabuf->resv, NULL);
+		r = dma_buf_pin(attach);
+		if (r) {
+			reservation_object_unlock(attach->dmabuf->resv);
+			return ERR_PTR(r);
+		}
+	}
+
 	sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
 	if (!sg_table)
 		sg_table = ERR_PTR(-ENOMEM);
 
+	if (!dma_buf_attachment_is_dynamic(attach) &&
+	    dma_buf_is_dynamic(attach->dmabuf)) {
+		if (IS_ERR(sg_table))
+			dma_buf_unpin(attach);
+		reservation_object_unlock(attach->dmabuf->resv);
+	}
+
 	if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
 		attach->sgt = sg_table;
 		attach->dir = direction;
@@ -802,10 +936,41 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
 	if (attach->sgt == sg_table)
 		return;
 
+	if (dma_buf_attachment_is_dynamic(attach))
+		reservation_object_assert_held(attach->dmabuf->resv);
+	else if (dma_buf_is_dynamic(attach->dmabuf))
+		reservation_object_lock(attach->dmabuf->resv, NULL);
+
 	attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
+
+	if (dma_buf_is_dynamic(attach->dmabuf) &&
+	    !dma_buf_attachment_is_dynamic(attach)) {
+		dma_buf_unpin(attach);
+		reservation_object_unlock(attach->dmabuf->resv);
+	}
 }
 EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
 
+/**
+ * dma_buf_move_notify - notify attachments that DMA-buf is moving
+ *
+ * @dmabuf:	[in]	buffer which is moving
+ *
+ * Informs all attachmenst that they need to destroy and recreated all their
+ * mappings.
+ */
+void dma_buf_move_notify(struct dma_buf *dmabuf)
+{
+	struct dma_buf_attachment *attach;
+
+	reservation_object_assert_held(dmabuf->resv);
+
+	list_for_each_entry(attach, &dmabuf->attachments, node)
+		if (attach->importer_ops && attach->importer_ops->move_notify)
+			attach->importer_ops->move_notify(attach);
+}
+EXPORT_SYMBOL_GPL(dma_buf_move_notify);
+
 /**
  * DOC: cpu access
  *
@@ -1225,10 +1390,12 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
 		seq_puts(s, "\tAttached Devices:\n");
 		attach_count = 0;
 
+		reservation_object_lock(buf_obj->resv, NULL);
 		list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
 			seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
 			attach_count++;
 		}
+		reservation_object_unlock(buf_obj->resv);
 
 		seq_printf(s, "Total %d devices attached\n\n",
 				attach_count);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 01ad5b942a6f..ccad2fc1f640 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -92,14 +92,40 @@ struct dma_buf_ops {
 	 */
 	void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
 
+	/**
+	 * @pin:
+	 *
+	 * This is called by dma_buf_pin and lets the exporter know that the
+	 * DMA-buf can't be moved any more.
+	 *
+	 * This is called with the dmabuf->resv object locked.
+	 *
+	 * This callback is optional.
+	 *
+	 * Returns:
+	 *
+	 * 0 on success, negative error code on failure.
+	 */
+	int (*pin)(struct dma_buf_attachment *attach);
+
+	/**
+	 * @unpin:
+	 *
+	 * This is called by dma_buf_unpin and lets the exporter know that the
+	 * DMA-buf can be moved again.
+	 *
+	 * This is called with the dmabuf->resv object locked.
+	 *
+	 * This callback is optional.
+	 */
+	void (*unpin)(struct dma_buf_attachment *attach);
+
 	/**
 	 * @map_dma_buf:
 	 *
 	 * This is called by dma_buf_map_attachment() and is used to map a
 	 * shared &dma_buf into device address space, and it is mandatory. It
-	 * can only be called if @attach has been called successfully. This
-	 * essentially pins the DMA buffer into place, and it cannot be moved
-	 * any more
+	 * can only be called if @attach has been called successfully.
 	 *
 	 * This call may sleep, e.g. when the backing storage first needs to be
 	 * allocated, or moved to a location suitable for all currently attached
@@ -120,6 +146,9 @@ struct dma_buf_ops {
 	 * any other kind of sharing that the exporter might wish to make
 	 * available to buffer-users.
 	 *
+	 * This is always called with the dmabuf->resv object locked when
+	 * the pin/unpin callbacks are implemented.
+	 *
 	 * Returns:
 	 *
 	 * A &sg_table scatter list of or the backing storage of the DMA buffer,
@@ -137,9 +166,6 @@ struct dma_buf_ops {
 	 *
 	 * This is called by dma_buf_unmap_attachment() and should unmap and
 	 * release the &sg_table allocated in @map_dma_buf, and it is mandatory.
-	 * It should also unpin the backing storage if this is the last mapping
-	 * of the DMA buffer, it the exporter supports backing storage
-	 * migration.
 	 */
 	void (*unmap_dma_buf)(struct dma_buf_attachment *,
 			      struct sg_table *,
@@ -330,6 +356,34 @@ struct dma_buf {
 	} cb_excl, cb_shared;
 };
 
+/**
+ * struct dma_buf_attach_ops - importer operations for an attachment
+ * @move_notify: [optional] notification that the DMA-buf is moving
+ *
+ * Attachment operations implemented by the importer.
+ */
+struct dma_buf_attach_ops {
+	/**
+	 * @move_notify
+	 *
+	 * If this callback is provided the framework can avoid pinning the
+	 * backing store while mappings exists.
+	 *
+	 * This callback is called with the lock of the reservation object
+	 * associated with the dma_buf held and the mapping function must be
+	 * called with this lock held as well. This makes sure that no mapping
+	 * is created concurrently with an ongoing move operation.
+	 *
+	 * Mappings stay valid and are not directly affected by this callback.
+	 * But the DMA-buf can now be in a different physical location, so all
+	 * mappings should be destroyed and re-created as soon as possible.
+	 *
+	 * New mappings can be created after this callback returns, and will
+	 * point to the new location of the DMA-buf.
+	 */
+	void (*move_notify)(struct dma_buf_attachment *attach);
+};
+
 /**
  * struct dma_buf_attachment - holds device-buffer attachment data
  * @dmabuf: buffer for this attachment.
@@ -338,6 +392,8 @@ struct dma_buf {
  * @sgt: cached mapping.
  * @dir: direction of cached mapping.
  * @priv: exporter specific attachment data.
+ * @importer_ops: importer operations for this attachment.
+ * @importer_priv: importer specific attachment data.
  *
  * This structure holds the attachment information between the dma_buf buffer
  * and its user device(s). The list contains one attachment struct per device
@@ -355,6 +411,9 @@ struct dma_buf_attachment {
 	struct sg_table *sgt;
 	enum dma_data_direction dir;
 	void *priv;
+
+	const struct dma_buf_attach_ops *importer_ops;
+	void *importer_priv;
 };
 
 /**
@@ -405,10 +464,42 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
 	get_file(dmabuf->file);
 }
 
+/**
+ * dma_buf_is_dynamic - check if a DMA-buf uses dynamic mappings.
+ * @dmabuf: the DMA-buf to check
+ *
+ * Returns true if a DMA-buf exporter wants to create dynamic sg table mappings
+ * for each attachment. False if only a single static sg table should be used.
+ */
+static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
+{
+	return !!dmabuf->ops->pin;
+}
+
+/**
+ * dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses dynamic
+ * mappinsg
+ * @attach: the DMA-buf attachment to check
+ *
+ * Returns true if a DMA-buf importer wants to use dynamic sg table mappings and
+ * calls the map/unmap functions with the reservation object locked.
+ */
+static inline bool
+dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
+{
+	return attach->importer_ops && attach->importer_ops->move_notify;
+}
+
 struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
-							struct device *dev);
+					  struct device *dev);
+struct dma_buf_attachment *
+dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
+		       const struct dma_buf_attach_ops *importer_ops,
+		       void *importer_priv);
 void dma_buf_detach(struct dma_buf *dmabuf,
-				struct dma_buf_attachment *dmabuf_attach);
+		    struct dma_buf_attachment *attach);
+int dma_buf_pin(struct dma_buf_attachment *attach);
+void dma_buf_unpin(struct dma_buf_attachment *attach);
 
 struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
 
@@ -420,6 +511,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
 					enum dma_data_direction);
 void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
 				enum dma_data_direction);
+void dma_buf_move_notify(struct dma_buf *dma_buf);
 int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
 			     enum dma_data_direction dir);
 int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/6] drm/ttm: remove the backing store if no placement is given

[Christian König]

Pipeline removal of the BOs backing store when no placement is given
during validation.

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

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7de667d482a..682a1a035b35 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1240,6 +1240,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
 	uint32_t new_flags;
 
 	reservation_object_assert_held(bo->resv);
+
+	/*
+	 * Remove the backing store if no placement is given.
+	 */
+	if (!placement->num_placement && !placement->num_busy_placement) {
+		ret = ttm_bo_pipeline_gutting(bo);
+		if (ret)
+			return ret;
+
+		return ttm_tt_create(bo, false);
+	}
+
 	/*
 	 * Check whether we need to move buffer.
 	 */
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 3/6] drm/ttm: use the parent resv for ghost objects v2

[Christian König]

This way we can even pipeline imported BO evictions.

v2: Limit this to only cases when the parent object uses a separate
    reservation object as well. This fixes another OOM problem.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 9f918b992f7e..5992ca821c69 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -517,9 +517,11 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo,
 	kref_init(&fbo->base.kref);
 	fbo->base.destroy = &ttm_transfered_destroy;
 	fbo->base.acc_size = 0;
-	fbo->base.resv = &fbo->base.ttm_resv;
-	reservation_object_init(fbo->base.resv);
-	ret = reservation_object_trylock(fbo->base.resv);
+	if (bo->resv == &bo->ttm_resv)
+		fbo->base.resv = &fbo->base.ttm_resv;
+
+	reservation_object_init(&fbo->base.ttm_resv);
+	ret = reservation_object_trylock(&fbo->base.ttm_resv);
 	WARN_ON(!ret);
 
 	*new_obj = &fbo->base;
@@ -716,7 +718,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
 		if (ret)
 			return ret;
 
-		reservation_object_add_excl_fence(ghost_obj->resv, fence);
+		reservation_object_add_excl_fence(&ghost_obj->ttm_resv, fence);
 
 		/**
 		 * If we're not moving to fixed memory, the TTM object
@@ -729,7 +731,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
 		else
 			bo->ttm = NULL;
 
-		ttm_bo_unreserve(ghost_obj);
+		reservation_object_unlock(&ghost_obj->ttm_resv);
 		ttm_bo_put(ghost_obj);
 	}
 
@@ -772,7 +774,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
 		if (ret)
 			return ret;
 
-		reservation_object_add_excl_fence(ghost_obj->resv, fence);
+		reservation_object_add_excl_fence(&ghost_obj->ttm_resv, fence);
 
 		/**
 		 * If we're not moving to fixed memory, the TTM object
@@ -785,7 +787,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
 		else
 			bo->ttm = NULL;
 
-		ttm_bo_unreserve(ghost_obj);
+		reservation_object_unlock(&ghost_obj->ttm_resv);
 		ttm_bo_put(ghost_obj);
 
 	} else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
@@ -841,7 +843,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
 	if (ret)
 		return ret;
 
-	ret = reservation_object_copy_fences(ghost->resv, bo->resv);
+	ret = reservation_object_copy_fences(&ghost->ttm_resv, bo->resv);
 	/* Last resort, wait for the BO to be idle when we are OOM */
 	if (ret)
 		ttm_bo_wait(bo, false, false);
@@ -850,7 +852,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
 	bo->mem.mem_type = TTM_PL_SYSTEM;
 	bo->ttm = NULL;
 
-	ttm_bo_unreserve(ghost);
+	reservation_object_unlock(&ghost->ttm_resv);
 	ttm_bo_put(ghost);
 
 	return 0;
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

[Christian König]

Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index dc63707e426f..0da512341194 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -28,6 +28,7 @@
 #include <linux/file.h>
 #include <linux/pagemap.h>
 #include <linux/sync_file.h>
+#include <linux/dma-buf.h>
 
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_syncobj.h>
@@ -414,7 +415,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
 	/* Don't move this buffer if we have depleted our allowance
 	 * to move it. Don't move anything if the threshold is zero.
 	 */
-	if (p->bytes_moved < p->bytes_moved_threshold) {
+	if (p->bytes_moved < p->bytes_moved_threshold &&
+	    (!bo->gem_base.dma_buf ||
+	    list_empty(&bo->gem_base.dma_buf->attachments))) {
 		if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
 		    (bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
 			/* And don't move a CPU_ACCESS_REQUIRED BO to limited
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 5/6] drm/amdgpu: add independent DMA-buf export v6

[Christian König]

The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.

Start by providing a separate DMA-buf export implementation in amdgpu.
This is also a prerequisite of unpinned DMA-buf handling.

v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
v4: rebase on top of new no_sgt_cache flag
v5: fix some warnings by including amdgpu_dma_buf.h
v6: fix locking for non amdgpu exports

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 210 +++++++++++++-------
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c     |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |   5 +
 4 files changed, 139 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 4809d4a5d72a..4541eae7aadb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -34,26 +34,11 @@
 #include "amdgpu.h"
 #include "amdgpu_display.h"
 #include "amdgpu_gem.h"
+#include "amdgpu_dma_buf.h"
 #include <drm/amdgpu_drm.h>
 #include <linux/dma-buf.h>
 #include <linux/dma-fence-array.h>
 
-/**
- * amdgpu_gem_prime_get_sg_table - &drm_driver.gem_prime_get_sg_table
- * implementation
- * @obj: GEM buffer object (BO)
- *
- * Returns:
- * A scatter/gather table for the pinned pages of the BO's memory.
- */
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
-	struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
-	int npages = bo->tbo.num_pages;
-
-	return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
 /**
  * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
  * @obj: GEM BO
@@ -179,92 +164,163 @@ __reservation_object_make_exclusive(struct reservation_object *obj)
 }
 
 /**
- * amdgpu_dma_buf_map_attach - &dma_buf_ops.attach implementation
- * @dma_buf: Shared DMA buffer
+ * amdgpu_dma_buf_attach - &dma_buf_ops.attach implementation
+ *
+ * @dmabuf: DMA-buf where we attach to
+ * @attach: attachment to add
+ *
+ * Add the attachment as user to the exported DMA-buf.
+ */
+static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
+				 struct dma_buf_attachment *attach)
+{
+	struct drm_gem_object *obj = dmabuf->priv;
+	struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+	int r;
+
+	if (attach->dev->driver == adev->dev->driver)
+		return 0;
+
+	r = amdgpu_bo_reserve(bo, false);
+	if (unlikely(r != 0))
+		return r;
+
+	/*
+	 * We only create shared fences for internal use, but importers
+	 * of the dmabuf rely on exclusive fences for implicitly
+	 * tracking write hazards. As any of the current fences may
+	 * correspond to a write, we need to convert all existing
+	 * fences on the reservation object into a single exclusive
+	 * fence.
+	 */
+	r = __reservation_object_make_exclusive(bo->tbo.resv);
+	if (r)
+		return r;
+
+	bo->prime_shared_count++;
+	amdgpu_bo_unreserve(bo);
+	return 0;
+}
+
+/**
+ * amdgpu_dma_buf_detach - &dma_buf_ops.detach implementation
+ *
+ * @dmabuf: DMA-buf where we remove the attachment from
+ * @attach: the attachment to remove
+ *
+ * Called when an attachment is removed from the DMA-buf.
+ */
+static void amdgpu_dma_buf_detach(struct dma_buf *dmabuf,
+				  struct dma_buf_attachment *attach)
+{
+	struct drm_gem_object *obj = dmabuf->priv;
+	struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+	struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+
+	if (attach->dev->driver != adev->dev->driver && bo->prime_shared_count)
+		bo->prime_shared_count--;
+}
+
+/**
+ * amdgpu_dma_buf_pin - &dma_buf_ops.pin implementation
+ *
+ * @attach: attachment to pin down
+ *
+ * Pin the BO which is backing the DMA-buf so that it can't move any more.
+ */
+static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
+{
+	struct drm_gem_object *obj = attach->dmabuf->priv;
+	struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+	/* pin buffer into GTT */
+	return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
+}
+
+/**
+ * amdgpu_dma_buf_unpin - &dma_buf_ops.unpin implementation
+ *
+ * @attach: attachment to unpin
+ *
+ * Unpin a previously pinned BO to make it movable again.
+ */
+static void amdgpu_dma_buf_unpin(struct dma_buf_attachment *attach)
+{
+	struct drm_gem_object *obj = attach->dmabuf->priv;
+	struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+	amdgpu_bo_unpin(bo);
+}
+
+/**
+ * amdgpu_dma_buf_map_dma_buf - &dma_buf_ops.map_dma_buf implementation
  * @attach: DMA-buf attachment
+ * @dir: DMA direction
  *
  * Makes sure that the shared DMA buffer can be accessed by the target device.
  * For now, simply pins it to the GTT domain, where it should be accessible by
  * all DMA devices.
  *
  * Returns:
- * 0 on success or a negative error code on failure.
+ * sg_table filled with the DMA addresses to use or ERR_PRT with negative error
+ * code.
  */
-static int amdgpu_dma_buf_map_attach(struct dma_buf *dma_buf,
-				     struct dma_buf_attachment *attach)
+static struct sg_table *
+amdgpu_dma_buf_map_dma_buf(struct dma_buf_attachment *attach,
+			   enum dma_data_direction dir)
 {
+	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;
 
-	r = drm_gem_map_attach(dma_buf, attach);
-	if (r)
-		return r;
+	if (!bo->pin_count) {
+		/* move buffer into GTT */
+		struct ttm_operation_ctx ctx = { false, false };
 
-	r = amdgpu_bo_reserve(bo, false);
-	if (unlikely(r != 0))
-		goto error_detach;
-
-
-	if (attach->dev->driver != adev->dev->driver) {
-		/*
-		 * We only create shared fences for internal use, but importers
-		 * of the dmabuf rely on exclusive fences for implicitly
-		 * tracking write hazards. As any of the current fences may
-		 * correspond to a write, we need to convert all existing
-		 * fences on the reservation object into a single exclusive
-		 * fence.
-		 */
-		r = __reservation_object_make_exclusive(bo->tbo.resv);
+		amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+		r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
 		if (r)
-			goto error_unreserve;
+			return ERR_PTR(r);
 	}
 
-	/* pin buffer into GTT */
-	r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
-	if (r)
-		goto error_unreserve;
+	sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
+	if (IS_ERR(sgt))
+		return sgt;
 
-	if (attach->dev->driver != adev->dev->driver)
-		bo->prime_shared_count++;
+	if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
+			      DMA_ATTR_SKIP_CPU_SYNC))
+		goto error_free;
 
-error_unreserve:
-	amdgpu_bo_unreserve(bo);
+	return sgt;
 
-error_detach:
-	if (r)
-		drm_gem_map_detach(dma_buf, attach);
-	return r;
+error_free:
+	sg_free_table(sgt);
+	kfree(sgt);
+	return ERR_PTR(-ENOMEM);
 }
 
 /**
- * amdgpu_dma_buf_map_detach - &dma_buf_ops.detach implementation
- * @dma_buf: Shared DMA buffer
+ * amdgpu_gem_unmap_dma_buf - &dma_buf_ops.unmap_dma_buf implementation
  * @attach: DMA-buf attachment
+ * @sgt: sg_table to unmap
+ * @dir: DMA direction
  *
  * This is called when a shared DMA buffer no longer needs to be accessible by
  * another device. For now, simply unpins the buffer from GTT.
  */
-static void amdgpu_dma_buf_map_detach(struct dma_buf *dma_buf,
-				      struct dma_buf_attachment *attach)
+static void amdgpu_dma_buf_unmap_dma_buf(struct dma_buf_attachment *attach,
+					 struct sg_table *sgt,
+					 enum dma_data_direction dir)
 {
-	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);
-	int ret = 0;
-
-	ret = amdgpu_bo_reserve(bo, true);
-	if (unlikely(ret != 0))
-		goto error;
+	if (!sgt)
+		return;
 
-	amdgpu_bo_unpin(bo);
-	if (attach->dev->driver != adev->dev->driver && bo->prime_shared_count)
-		bo->prime_shared_count--;
-	amdgpu_bo_unreserve(bo);
-
-error:
-	drm_gem_map_detach(dma_buf, attach);
+	dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+	sg_free_table(sgt);
+	kfree(sgt);
 }
 
 /**
@@ -322,10 +378,12 @@ static int amdgpu_dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
 }
 
 const struct dma_buf_ops amdgpu_dmabuf_ops = {
-	.attach = amdgpu_dma_buf_map_attach,
-	.detach = amdgpu_dma_buf_map_detach,
-	.map_dma_buf = drm_gem_map_dma_buf,
-	.unmap_dma_buf = drm_gem_unmap_dma_buf,
+	.attach = amdgpu_dma_buf_attach,
+	.detach = amdgpu_dma_buf_detach,
+	.pin = amdgpu_dma_buf_pin,
+	.unpin = amdgpu_dma_buf_unpin,
+	.map_dma_buf = amdgpu_dma_buf_map_dma_buf,
+	.unmap_dma_buf = amdgpu_dma_buf_unmap_dma_buf,
 	.release = drm_gem_dmabuf_release,
 	.begin_cpu_access = amdgpu_dma_buf_begin_cpu_access,
 	.mmap = drm_gem_dmabuf_mmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index 7f73a4f94204..0affdfa9f22e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -25,7 +25,6 @@
 
 #include <drm/drm_gem.h>
 
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *
 amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
 				 struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8e1b269351e8..bc28515a79b0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1334,7 +1334,6 @@ static struct drm_driver kms_driver = {
 	.gem_prime_export = amdgpu_gem_prime_export,
 	.gem_prime_import = amdgpu_gem_prime_import,
 	.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
-	.gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
 	.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
 	.gem_prime_vmap = amdgpu_gem_prime_vmap,
 	.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 16f96f2e3671..1972fbbbb091 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -31,6 +31,7 @@
  */
 #include <linux/list.h>
 #include <linux/slab.h>
+#include <linux/dma-buf.h>
 
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_cache.h>
@@ -1194,6 +1195,10 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
 
 	amdgpu_bo_kunmap(abo);
 
+	if (abo->gem_base.dma_buf && !abo->gem_base.import_attach &&
+	    bo->mem.mem_type != TTM_PL_SYSTEM)
+		dma_buf_move_notify(abo->gem_base.dma_buf);
+
 	/* remember the eviction */
 	if (evict)
 		atomic64_inc(&adev->num_evictions);
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 6/6] drm/amdgpu: add independent DMA-buf import v7

[Christian König]

Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.

v2: enable for all exporters, not just amdgpu, fix invalidation
    handling, lock reservation object while setting callback
v3: change to new dma_buf attach interface
v4: split out from unpinned DMA-buf work
v5: rebased and cleanup on new DMA-buf interface
v6: squash with invalidation callback change,
    stop using _(map|unmap)_locked
v7: drop invalidations when the BO is already in system domain

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 68 ++++++++++++++++-----
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |  4 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c     |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c     | 32 ++++++++--
 5 files changed, 86 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 4541eae7aadb..2630393da35c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -423,31 +423,28 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object *gobj,
 }
 
 /**
- * amdgpu_gem_prime_import_sg_table - &drm_driver.gem_prime_import_sg_table
- * implementation
+ * amdgpu_dma_buf_create_obj - create BO for DMA-buf import
+ *
  * @dev: DRM device
- * @attach: DMA-buf attachment
- * @sg: Scatter/gather table
+ * @dma_buf: DMA-buf
  *
- * Imports shared DMA buffer memory exported by another device.
+ * Creates an empty SG BO for DMA-buf import.
  *
  * Returns:
  * A new GEM BO of the given DRM device, representing the memory
  * described by the given DMA-buf attachment and scatter/gather table.
  */
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-				 struct dma_buf_attachment *attach,
-				 struct sg_table *sg)
+static struct drm_gem_object *
+amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
 {
-	struct reservation_object *resv = attach->dmabuf->resv;
+	struct reservation_object *resv = dma_buf->resv;
 	struct amdgpu_device *adev = dev->dev_private;
 	struct amdgpu_bo *bo;
 	struct amdgpu_bo_param bp;
 	int ret;
 
 	memset(&bp, 0, sizeof(bp));
-	bp.size = attach->dmabuf->size;
+	bp.size = dma_buf->size;
 	bp.byte_align = PAGE_SIZE;
 	bp.domain = AMDGPU_GEM_DOMAIN_CPU;
 	bp.flags = 0;
@@ -458,11 +455,9 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
 	if (ret)
 		goto error;
 
-	bo->tbo.sg = sg;
-	bo->tbo.ttm->sg = sg;
 	bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
 	bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
-	if (attach->dmabuf->ops != &amdgpu_dmabuf_ops)
+	if (dma_buf->ops != &amdgpu_dmabuf_ops)
 		bo->prime_shared_count = 1;
 
 	ww_mutex_unlock(&resv->lock);
@@ -473,6 +468,35 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
 	return ERR_PTR(ret);
 }
 
+/**
+ * amdgpu_gem_prime_move_notify - &attach.move_notify implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_gem_prime_move_notify(struct dma_buf_attachment *attach)
+{
+	struct ttm_operation_ctx ctx = { false, false };
+	struct drm_gem_object *obj = attach->importer_priv;
+	struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+	struct ttm_placement placement = {};
+	int r;
+
+	if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
+		return;
+
+	r = ttm_bo_validate(&bo->tbo, &placement, &ctx);
+	if (r)
+		DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
+}
+
+static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
+	.move_notify = amdgpu_gem_prime_move_notify
+};
+
 /**
  * amdgpu_gem_prime_import - &drm_driver.gem_prime_import implementation
  * @dev: DRM device
@@ -487,6 +511,7 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
 struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
 					    struct dma_buf *dma_buf)
 {
+	struct dma_buf_attachment *attach;
 	struct drm_gem_object *obj;
 
 	if (dma_buf->ops == &amdgpu_dmabuf_ops) {
@@ -501,5 +526,18 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
 		}
 	}
 
-	return drm_gem_prime_import(dev, dma_buf);
+	obj = amdgpu_dma_buf_create_obj(dev, dma_buf);
+	if (IS_ERR(obj))
+		return obj;
+
+	attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
+					&amdgpu_dma_buf_attach_ops, obj);
+	if (IS_ERR(attach)) {
+		drm_gem_object_put(obj);
+		return ERR_CAST(attach);
+	}
+
+	get_dma_buf(dma_buf);
+	obj->import_attach = attach;
+	return obj;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index 0affdfa9f22e..6afc470ca182 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -25,10 +25,6 @@
 
 #include <drm/drm_gem.h>
 
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-				 struct dma_buf_attachment *attach,
-				 struct sg_table *sg);
 struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object *gobj,
 					int flags);
 struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index bc28515a79b0..836f23dac04b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1334,7 +1334,6 @@ static struct drm_driver kms_driver = {
 	.gem_prime_export = amdgpu_gem_prime_export,
 	.gem_prime_import = amdgpu_gem_prime_import,
 	.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
-	.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
 	.gem_prime_vmap = amdgpu_gem_prime_vmap,
 	.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
 	.gem_prime_mmap = amdgpu_gem_prime_mmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 1972fbbbb091..ddb6a12c4924 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -850,6 +850,9 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32 domain,
 		return 0;
 	}
 
+	if (bo->gem_base.import_attach)
+		dma_buf_pin(bo->gem_base.import_attach);
+
 	bo->flags |= AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS;
 	/* force to pin into visible video ram */
 	if (!(bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS))
@@ -933,6 +936,9 @@ int amdgpu_bo_unpin(struct amdgpu_bo *bo)
 
 	amdgpu_bo_subtract_pin_size(bo);
 
+	if (bo->gem_base.import_attach)
+		dma_buf_unpin(bo->gem_base.import_attach);
+
 	for (i = 0; i < bo->placement.num_placement; i++) {
 		bo->placements[i].lpfn = 0;
 		bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d81bebf76310..c89fa58a7914 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -39,6 +39,7 @@
 #include <linux/slab.h>
 #include <linux/swap.h>
 #include <linux/swiotlb.h>
+#include <linux/dma-buf.h>
 
 #include <drm/ttm/ttm_bo_api.h>
 #include <drm/ttm/ttm_bo_driver.h>
@@ -711,6 +712,7 @@ static unsigned long amdgpu_ttm_io_mem_pfn(struct ttm_buffer_object *bo,
  */
 struct amdgpu_ttm_tt {
 	struct ttm_dma_tt	ttm;
+	struct drm_gem_object	*gobj;
 	u64			offset;
 	uint64_t		userptr;
 	struct task_struct	*usertask;
@@ -1198,6 +1200,7 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct ttm_buffer_object *bo,
 		return NULL;
 	}
 	gtt->ttm.ttm.func = &amdgpu_backend_func;
+	gtt->gobj = &ttm_to_amdgpu_bo(bo)->gem_base;
 
 	/* allocate space for the uninitialized page entries */
 	if (ttm_sg_tt_init(&gtt->ttm, bo, page_flags)) {
@@ -1218,7 +1221,6 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
 {
 	struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
 	struct amdgpu_ttm_tt *gtt = (void *)ttm;
-	bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
 
 	/* user pages are bound by amdgpu_ttm_tt_pin_userptr() */
 	if (gtt && gtt->userptr) {
@@ -1231,7 +1233,19 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
 		return 0;
 	}
 
-	if (slave && ttm->sg) {
+	if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
+		if (!ttm->sg) {
+			struct dma_buf_attachment *attach;
+			struct sg_table *sgt;
+
+			attach = gtt->gobj->import_attach;
+			sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+			if (IS_ERR(sgt))
+				return PTR_ERR(sgt);
+
+			ttm->sg = sgt;
+		}
+
 		drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
 						 gtt->ttm.dma_address,
 						 ttm->num_pages);
@@ -1258,9 +1272,8 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
  */
 static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
 {
-	struct amdgpu_device *adev;
 	struct amdgpu_ttm_tt *gtt = (void *)ttm;
-	bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
+	struct amdgpu_device *adev;
 
 	if (gtt && gtt->userptr) {
 		amdgpu_ttm_tt_set_user_pages(ttm, NULL);
@@ -1269,7 +1282,16 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
 		return;
 	}
 
-	if (slave)
+	if (ttm->sg && gtt->gobj->import_attach) {
+		struct dma_buf_attachment *attach;
+
+		attach = gtt->gobj->import_attach;
+		dma_buf_unmap_attachment(attach, ttm->sg, DMA_BIDIRECTIONAL);
+		ttm->sg = NULL;
+		return;
+	}
+
+	if (ttm->page_flags & TTM_PAGE_FLAG_SG)
 		return;
 
 	adev = amdgpu_ttm_adev(ttm->bdev);
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Daniel Vetter]

Hi Christian,

On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
> held.
> 
> On the importer side we add an optional invalidate callback. This callback is
> used by the exporter to inform the importers that their mappings should be
> destroyed as soon as possible.
> 
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
> 
> v2: don't try to invalidate mappings when the callback is NULL,
>     lock the reservation obj while using the attachments,
>     add helper to set the callback
> v3: move flag for invalidation support into the DMA-buf,
>     use new attach_info structure to set the callback
> v4: use importer_priv field instead of mangling exporter priv.
> v5: drop invalidation_supported flag
> v6: squash together with pin/unpin changes
> v7: pin/unpin takes an attachment now
> v8: nuke dma_buf_attachment_(map|unmap)_locked,
>     everything is now handled backward compatible
> v9: always cache when export/importer don't agree on dynamic handling
> v10: minimal style cleanup
> v11: drop automatically re-entry avoidance
> v12: rename callback to move_notify
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>  drivers/dma-buf/dma-buf.c | 179 ++++++++++++++++++++++++++++++++++++--
>  include/linux/dma-buf.h   | 108 +++++++++++++++++++++--
>  2 files changed, 273 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 6c15deb5d4ad..216f76109f3f 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
>  		return ERR_PTR(-EINVAL);
>  	}
>  
> +	if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
> +		return ERR_PTR(-EINVAL);
> +
>  	if (!try_module_get(exp_info->owner))
>  		return ERR_PTR(-ENOENT);
>  
> @@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
>  EXPORT_SYMBOL_GPL(dma_buf_put);
>  
>  /**
> - * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
> + * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list; optionally,
>   * calls attach() of dma_buf_ops to allow device-specific attach functionality
> - * @dmabuf:	[in]	buffer to attach device to.
> - * @dev:	[in]	device to be attached.
> + * @dmabuf:		[in]	buffer to attach device to.
> + * @dev:		[in]	device to be attached.
> + * @importer_ops	[in]	importer operations for the attachment
> + * @importer_priv	[in]	importer private pointer for the attachment
>   *
>   * Returns struct dma_buf_attachment pointer for this attachment. Attachments
>   * must be cleaned up by calling dma_buf_detach().
> @@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
>   * accessible to @dev, and cannot be moved to a more suitable place. This is
>   * indicated with the error code -EBUSY.
>   */
> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> -					  struct device *dev)
> +struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> +		       const struct dma_buf_attach_ops *importer_ops,
> +		       void *importer_priv)
>  {
>  	struct dma_buf_attachment *attach;
>  	int ret;
> @@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>  
>  	attach->dev = dev;
>  	attach->dmabuf = dmabuf;
> +	attach->importer_ops = importer_ops;
> +	attach->importer_priv = importer_priv;
>  
>  	mutex_lock(&dmabuf->lock);
>  
> @@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>  		if (ret)
>  			goto err_attach;
>  	}
> +	reservation_object_lock(dmabuf->resv, NULL);
>  	list_add(&attach->node, &dmabuf->attachments);
> +	reservation_object_unlock(dmabuf->resv);
>  
>  	mutex_unlock(&dmabuf->lock);
>  
> +	/* When either the importer or the exporter can't handle dynamic
> +	 * mappings we cache the mapping here to avoid issues with the
> +	 * reservation object lock.
> +	 */
> +	if (dma_buf_attachment_is_dynamic(attach) !=
> +	    dma_buf_is_dynamic(dmabuf)) {
> +		struct sg_table *sgt;
> +
> +		if (dma_buf_is_dynamic(attach->dmabuf)) {
> +			reservation_object_lock(attach->dmabuf->resv, NULL);
> +			ret = dma_buf_pin(attach);
> +			if (ret)
> +				goto err_unlock;
> +		}
> +
> +		sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> +		if (!sgt)
> +			sgt = ERR_PTR(-ENOMEM);
> +		if (IS_ERR(sgt)) {
> +			ret = PTR_ERR(sgt);
> +			goto err_unpin;
> +		}
> +		if (dma_buf_is_dynamic(attach->dmabuf))
> +			reservation_object_unlock(attach->dmabuf->resv);
> +		attach->sgt = sgt;
> +		attach->dir = DMA_BIDIRECTIONAL;
> +	}
> +
>  	return attach;
>  
>  err_attach:
>  	kfree(attach);
>  	mutex_unlock(&dmabuf->lock);
>  	return ERR_PTR(ret);
> +
> +err_unpin:
> +	if (dma_buf_is_dynamic(attach->dmabuf))
> +		dma_buf_unpin(attach);
> +
> +err_unlock:
> +	if (dma_buf_is_dynamic(attach->dmabuf))
> +		reservation_object_unlock(attach->dmabuf->resv);
> +
> +	dma_buf_detach(dmabuf, attach);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
> +
> +/**
> + * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
> + * @dmabuf:	[in]	buffer to attach device to.
> + * @dev:	[in]	device to be attached.
> + *
> + * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a static
> + * mapping.
> + */
> +struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> +					  struct device *dev)
> +{
> +	return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_attach);
>  
> @@ -717,11 +782,22 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
>  	if (WARN_ON(!dmabuf || !attach))
>  		return;
>  
> -	if (attach->sgt)
> +	if (attach->sgt) {
> +		if (dma_buf_is_dynamic(attach->dmabuf))
> +			reservation_object_lock(attach->dmabuf->resv, NULL);
> +
>  		dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir);
>  
> +		if (dma_buf_is_dynamic(attach->dmabuf)) {
> +			dma_buf_unpin(attach);
> +			reservation_object_unlock(attach->dmabuf->resv);
> +		}
> +	}
> +
>  	mutex_lock(&dmabuf->lock);

Time to ditch dmabuf->lock in favour of the reservation obj? We have a
fallback resv_obj in struct dma_buf already, so this is never null, and I
think would clean up the code a bit.


> +	reservation_object_lock(dmabuf->resv, NULL);
>  	list_del(&attach->node);
> +	reservation_object_unlock(dmabuf->resv);
>  	if (dmabuf->ops->detach)
>  		dmabuf->ops->detach(dmabuf, attach);
>  
> @@ -730,6 +806,44 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_detach);
>  
> +/**
> + * dma_buf_pin - Lock down the DMA-buf
> + *
> + * @attach:	[in]	attachment which should be pinned
> + *
> + * Returns:
> + * 0 on success, negative error code on failure.
> + */
> +int dma_buf_pin(struct dma_buf_attachment *attach)
> +{
> +	struct dma_buf *dmabuf = attach->dmabuf;
> +	int ret = 0;
> +
> +	reservation_object_assert_held(dmabuf->resv);
> +
> +	if (dmabuf->ops->pin)
> +		ret = dmabuf->ops->pin(attach);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_pin);
> +
> +/**
> + * dma_buf_unpin - Remove lock from DMA-buf
> + *
> + * @attach:	[in]	attachment which should be unpinned
> + */
> +void dma_buf_unpin(struct dma_buf_attachment *attach)
> +{
> +	struct dma_buf *dmabuf = attach->dmabuf;
> +
> +	reservation_object_assert_held(dmabuf->resv);
> +
> +	if (dmabuf->ops->unpin)
> +		dmabuf->ops->unpin(attach);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_unpin);
> +
>  /**
>   * dma_buf_map_attachment - Returns the scatterlist table of the attachment;
>   * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
> @@ -749,6 +863,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>  					enum dma_data_direction direction)
>  {
>  	struct sg_table *sg_table;
> +	int r;
>  
>  	might_sleep();
>  
> @@ -767,10 +882,29 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>  		return attach->sgt;
>  	}
>  
> +	if (dma_buf_attachment_is_dynamic(attach)) {
> +		reservation_object_assert_held(attach->dmabuf->resv);
> +
> +	} else if (dma_buf_is_dynamic(attach->dmabuf)) {
> +		reservation_object_lock(attach->dmabuf->resv, NULL);
> +		r = dma_buf_pin(attach);
> +		if (r) {
> +			reservation_object_unlock(attach->dmabuf->resv);
> +			return ERR_PTR(r);
> +		}
> +	}

With this design (because we can't cache at attach time unconditionally)
we inflict the reservation lock on all importers. So needs:

	} else {
		/* neither importer nor exporter are dynamice */
		might_lock(dmabuf->resv->ww_mutex);
	}

Same for dma_buf_unmap_attachment.

I also expect that this will blow up in intel-gfx-ci :-/ I did look at
previous intel-gfx-ci runs of your series, and the last one that did pass
was the one that still had the caching in _attach():

Geez I was sooooooooo locking forward to slapping an r-b on this and
volunteering myself to polish the kerneldoc (which isn't great, but also
pre-existing condition plus on my todo list anyway) :-(

> +
>  	sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
>  	if (!sg_table)
>  		sg_table = ERR_PTR(-ENOMEM);
>  
> +	if (!dma_buf_attachment_is_dynamic(attach) &&
> +	    dma_buf_is_dynamic(attach->dmabuf)) {
> +		if (IS_ERR(sg_table))
> +			dma_buf_unpin(attach);
> +		reservation_object_unlock(attach->dmabuf->resv);
> +	}
> +
>  	if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
>  		attach->sgt = sg_table;
>  		attach->dir = direction;
> @@ -802,10 +936,41 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
>  	if (attach->sgt == sg_table)
>  		return;
>  
> +	if (dma_buf_attachment_is_dynamic(attach))
> +		reservation_object_assert_held(attach->dmabuf->resv);
> +	else if (dma_buf_is_dynamic(attach->dmabuf))
> +		reservation_object_lock(attach->dmabuf->resv, NULL);
> +
>  	attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
> +
> +	if (dma_buf_is_dynamic(attach->dmabuf) &&
> +	    !dma_buf_attachment_is_dynamic(attach)) {
> +		dma_buf_unpin(attach);
> +		reservation_object_unlock(attach->dmabuf->resv);
> +	}
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>  
> +/**
> + * dma_buf_move_notify - notify attachments that DMA-buf is moving
> + *
> + * @dmabuf:	[in]	buffer which is moving
> + *
> + * Informs all attachmenst that they need to destroy and recreated all their
> + * mappings.
> + */
> +void dma_buf_move_notify(struct dma_buf *dmabuf)
> +{
> +	struct dma_buf_attachment *attach;
> +
> +	reservation_object_assert_held(dmabuf->resv);
> +
> +	list_for_each_entry(attach, &dmabuf->attachments, node)
> +		if (attach->importer_ops && attach->importer_ops->move_notify)
> +			attach->importer_ops->move_notify(attach);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_move_notify);
> +
>  /**
>   * DOC: cpu access
>   *
> @@ -1225,10 +1390,12 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
>  		seq_puts(s, "\tAttached Devices:\n");
>  		attach_count = 0;
>  
> +		reservation_object_lock(buf_obj->resv, NULL);
>  		list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
>  			seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
>  			attach_count++;
>  		}
> +		reservation_object_unlock(buf_obj->resv);

Yeah definitely time to retire dmabuf->lock I think.

Cheers, Daniel

>  
>  		seq_printf(s, "Total %d devices attached\n\n",
>  				attach_count);
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 01ad5b942a6f..ccad2fc1f640 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -92,14 +92,40 @@ struct dma_buf_ops {
>  	 */
>  	void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
>  
> +	/**
> +	 * @pin:
> +	 *
> +	 * This is called by dma_buf_pin and lets the exporter know that the
> +	 * DMA-buf can't be moved any more.
> +	 *
> +	 * This is called with the dmabuf->resv object locked.
> +	 *
> +	 * This callback is optional.
> +	 *
> +	 * Returns:
> +	 *
> +	 * 0 on success, negative error code on failure.
> +	 */
> +	int (*pin)(struct dma_buf_attachment *attach);
> +
> +	/**
> +	 * @unpin:
> +	 *
> +	 * This is called by dma_buf_unpin and lets the exporter know that the
> +	 * DMA-buf can be moved again.
> +	 *
> +	 * This is called with the dmabuf->resv object locked.
> +	 *
> +	 * This callback is optional.
> +	 */
> +	void (*unpin)(struct dma_buf_attachment *attach);
> +
>  	/**
>  	 * @map_dma_buf:
>  	 *
>  	 * This is called by dma_buf_map_attachment() and is used to map a
>  	 * shared &dma_buf into device address space, and it is mandatory. It
> -	 * can only be called if @attach has been called successfully. This
> -	 * essentially pins the DMA buffer into place, and it cannot be moved
> -	 * any more
> +	 * can only be called if @attach has been called successfully.
>  	 *
>  	 * This call may sleep, e.g. when the backing storage first needs to be
>  	 * allocated, or moved to a location suitable for all currently attached
> @@ -120,6 +146,9 @@ struct dma_buf_ops {
>  	 * any other kind of sharing that the exporter might wish to make
>  	 * available to buffer-users.
>  	 *
> +	 * This is always called with the dmabuf->resv object locked when
> +	 * the pin/unpin callbacks are implemented.
> +	 *
>  	 * Returns:
>  	 *
>  	 * A &sg_table scatter list of or the backing storage of the DMA buffer,
> @@ -137,9 +166,6 @@ struct dma_buf_ops {
>  	 *
>  	 * This is called by dma_buf_unmap_attachment() and should unmap and
>  	 * release the &sg_table allocated in @map_dma_buf, and it is mandatory.
> -	 * It should also unpin the backing storage if this is the last mapping
> -	 * of the DMA buffer, it the exporter supports backing storage
> -	 * migration.
>  	 */
>  	void (*unmap_dma_buf)(struct dma_buf_attachment *,
>  			      struct sg_table *,
> @@ -330,6 +356,34 @@ struct dma_buf {
>  	} cb_excl, cb_shared;
>  };
>  
> +/**
> + * struct dma_buf_attach_ops - importer operations for an attachment
> + * @move_notify: [optional] notification that the DMA-buf is moving
> + *
> + * Attachment operations implemented by the importer.
> + */
> +struct dma_buf_attach_ops {
> +	/**
> +	 * @move_notify
> +	 *
> +	 * If this callback is provided the framework can avoid pinning the
> +	 * backing store while mappings exists.
> +	 *
> +	 * This callback is called with the lock of the reservation object
> +	 * associated with the dma_buf held and the mapping function must be
> +	 * called with this lock held as well. This makes sure that no mapping
> +	 * is created concurrently with an ongoing move operation.
> +	 *
> +	 * Mappings stay valid and are not directly affected by this callback.
> +	 * But the DMA-buf can now be in a different physical location, so all
> +	 * mappings should be destroyed and re-created as soon as possible.
> +	 *
> +	 * New mappings can be created after this callback returns, and will
> +	 * point to the new location of the DMA-buf.
> +	 */
> +	void (*move_notify)(struct dma_buf_attachment *attach);
> +};
> +
>  /**
>   * struct dma_buf_attachment - holds device-buffer attachment data
>   * @dmabuf: buffer for this attachment.
> @@ -338,6 +392,8 @@ struct dma_buf {
>   * @sgt: cached mapping.
>   * @dir: direction of cached mapping.
>   * @priv: exporter specific attachment data.
> + * @importer_ops: importer operations for this attachment.
> + * @importer_priv: importer specific attachment data.
>   *
>   * This structure holds the attachment information between the dma_buf buffer
>   * and its user device(s). The list contains one attachment struct per device
> @@ -355,6 +411,9 @@ struct dma_buf_attachment {
>  	struct sg_table *sgt;
>  	enum dma_data_direction dir;
>  	void *priv;
> +
> +	const struct dma_buf_attach_ops *importer_ops;
> +	void *importer_priv;
>  };
>  
>  /**
> @@ -405,10 +464,42 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
>  	get_file(dmabuf->file);
>  }
>  
> +/**
> + * dma_buf_is_dynamic - check if a DMA-buf uses dynamic mappings.
> + * @dmabuf: the DMA-buf to check
> + *
> + * Returns true if a DMA-buf exporter wants to create dynamic sg table mappings
> + * for each attachment. False if only a single static sg table should be used.
> + */
> +static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
> +{
> +	return !!dmabuf->ops->pin;
> +}
> +
> +/**
> + * dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses dynamic
> + * mappinsg
> + * @attach: the DMA-buf attachment to check
> + *
> + * Returns true if a DMA-buf importer wants to use dynamic sg table mappings and
> + * calls the map/unmap functions with the reservation object locked.
> + */
> +static inline bool
> +dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
> +{
> +	return attach->importer_ops && attach->importer_ops->move_notify;
> +}
> +
>  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> -							struct device *dev);
> +					  struct device *dev);
> +struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> +		       const struct dma_buf_attach_ops *importer_ops,
> +		       void *importer_priv);
>  void dma_buf_detach(struct dma_buf *dmabuf,
> -				struct dma_buf_attachment *dmabuf_attach);
> +		    struct dma_buf_attachment *attach);
> +int dma_buf_pin(struct dma_buf_attachment *attach);
> +void dma_buf_unpin(struct dma_buf_attachment *attach);
>  
>  struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
>  
> @@ -420,6 +511,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
>  					enum dma_data_direction);
>  void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
>  				enum dma_data_direction);
> +void dma_buf_move_notify(struct dma_buf *dma_buf);
>  int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
>  			     enum dma_data_direction dir);
>  int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
> -- 
> 2.17.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Christian König]

Am 25.06.19 um 16:35 schrieb Daniel Vetter:
> Hi Christian,
>
> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
>> On the exporter side we add optional explicit pinning callbacks. If those
>> callbacks are implemented the framework no longer caches sg tables and the
>> map/unmap callbacks are always called with the lock of the reservation object
>> held.
>>
>> On the importer side we add an optional invalidate callback. This callback is
>> used by the exporter to inform the importers that their mappings should be
>> destroyed as soon as possible.
>>
>> This allows the exporter to provide the mappings without the need to pin
>> the backing store.
>>
>> v2: don't try to invalidate mappings when the callback is NULL,
>>      lock the reservation obj while using the attachments,
>>      add helper to set the callback
>> v3: move flag for invalidation support into the DMA-buf,
>>      use new attach_info structure to set the callback
>> v4: use importer_priv field instead of mangling exporter priv.
>> v5: drop invalidation_supported flag
>> v6: squash together with pin/unpin changes
>> v7: pin/unpin takes an attachment now
>> v8: nuke dma_buf_attachment_(map|unmap)_locked,
>>      everything is now handled backward compatible
>> v9: always cache when export/importer don't agree on dynamic handling
>> v10: minimal style cleanup
>> v11: drop automatically re-entry avoidance
>> v12: rename callback to move_notify
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/dma-buf/dma-buf.c | 179 ++++++++++++++++++++++++++++++++++++--
>>   include/linux/dma-buf.h   | 108 +++++++++++++++++++++--
>>   2 files changed, 273 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 6c15deb5d4ad..216f76109f3f 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
>>   		return ERR_PTR(-EINVAL);
>>   	}
>>   
>> +	if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
>> +		return ERR_PTR(-EINVAL);
>> +
>>   	if (!try_module_get(exp_info->owner))
>>   		return ERR_PTR(-ENOENT);
>>   
>> @@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
>>   EXPORT_SYMBOL_GPL(dma_buf_put);
>>   
>>   /**
>> - * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
>> + * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list; optionally,
>>    * calls attach() of dma_buf_ops to allow device-specific attach functionality
>> - * @dmabuf:	[in]	buffer to attach device to.
>> - * @dev:	[in]	device to be attached.
>> + * @dmabuf:		[in]	buffer to attach device to.
>> + * @dev:		[in]	device to be attached.
>> + * @importer_ops	[in]	importer operations for the attachment
>> + * @importer_priv	[in]	importer private pointer for the attachment
>>    *
>>    * Returns struct dma_buf_attachment pointer for this attachment. Attachments
>>    * must be cleaned up by calling dma_buf_detach().
>> @@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
>>    * accessible to @dev, and cannot be moved to a more suitable place. This is
>>    * indicated with the error code -EBUSY.
>>    */
>> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>> -					  struct device *dev)
>> +struct dma_buf_attachment *
>> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
>> +		       const struct dma_buf_attach_ops *importer_ops,
>> +		       void *importer_priv)
>>   {
>>   	struct dma_buf_attachment *attach;
>>   	int ret;
>> @@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>>   
>>   	attach->dev = dev;
>>   	attach->dmabuf = dmabuf;
>> +	attach->importer_ops = importer_ops;
>> +	attach->importer_priv = importer_priv;
>>   
>>   	mutex_lock(&dmabuf->lock);
>>   
>> @@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>>   		if (ret)
>>   			goto err_attach;
>>   	}
>> +	reservation_object_lock(dmabuf->resv, NULL);
>>   	list_add(&attach->node, &dmabuf->attachments);
>> +	reservation_object_unlock(dmabuf->resv);
>>   
>>   	mutex_unlock(&dmabuf->lock);
>>   
>> +	/* When either the importer or the exporter can't handle dynamic
>> +	 * mappings we cache the mapping here to avoid issues with the
>> +	 * reservation object lock.
>> +	 */
>> +	if (dma_buf_attachment_is_dynamic(attach) !=
>> +	    dma_buf_is_dynamic(dmabuf)) {
>> +		struct sg_table *sgt;
>> +
>> +		if (dma_buf_is_dynamic(attach->dmabuf)) {
>> +			reservation_object_lock(attach->dmabuf->resv, NULL);
>> +			ret = dma_buf_pin(attach);
>> +			if (ret)
>> +				goto err_unlock;
>> +		}
>> +
>> +		sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
>> +		if (!sgt)
>> +			sgt = ERR_PTR(-ENOMEM);
>> +		if (IS_ERR(sgt)) {
>> +			ret = PTR_ERR(sgt);
>> +			goto err_unpin;
>> +		}
>> +		if (dma_buf_is_dynamic(attach->dmabuf))
>> +			reservation_object_unlock(attach->dmabuf->resv);
>> +		attach->sgt = sgt;
>> +		attach->dir = DMA_BIDIRECTIONAL;
>> +	}
>> +
>>   	return attach;
>>   
>>   err_attach:
>>   	kfree(attach);
>>   	mutex_unlock(&dmabuf->lock);
>>   	return ERR_PTR(ret);
>> +
>> +err_unpin:
>> +	if (dma_buf_is_dynamic(attach->dmabuf))
>> +		dma_buf_unpin(attach);
>> +
>> +err_unlock:
>> +	if (dma_buf_is_dynamic(attach->dmabuf))
>> +		reservation_object_unlock(attach->dmabuf->resv);
>> +
>> +	dma_buf_detach(dmabuf, attach);
>> +	return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
>> +
>> +/**
>> + * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
>> + * @dmabuf:	[in]	buffer to attach device to.
>> + * @dev:	[in]	device to be attached.
>> + *
>> + * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a static
>> + * mapping.
>> + */
>> +struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>> +					  struct device *dev)
>> +{
>> +	return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
>>   }
>>   EXPORT_SYMBOL_GPL(dma_buf_attach);
>>   
>> @@ -717,11 +782,22 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
>>   	if (WARN_ON(!dmabuf || !attach))
>>   		return;
>>   
>> -	if (attach->sgt)
>> +	if (attach->sgt) {
>> +		if (dma_buf_is_dynamic(attach->dmabuf))
>> +			reservation_object_lock(attach->dmabuf->resv, NULL);
>> +
>>   		dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir);
>>   
>> +		if (dma_buf_is_dynamic(attach->dmabuf)) {
>> +			dma_buf_unpin(attach);
>> +			reservation_object_unlock(attach->dmabuf->resv);
>> +		}
>> +	}
>> +
>>   	mutex_lock(&dmabuf->lock);
> Time to ditch dmabuf->lock in favour of the reservation obj? We have a
> fallback resv_obj in struct dma_buf already, so this is never null, and I
> think would clean up the code a bit.

Yeah, thought about that as well. But then decided against it for now.

Key point is that exporters currently doesn't care about dmabuf->lock, 
but they do care about the reservation lock.

So we will probably have a bunch of cases where we have to fix up 
exporters because they will try to grab the reservation lock as well.

On the other hand we maybe not need a lock at all here if we just can 
live with multiple attach/detach callbacks running in parallel.

>
>
>> +	reservation_object_lock(dmabuf->resv, NULL);
>>   	list_del(&attach->node);
>> +	reservation_object_unlock(dmabuf->resv);
>>   	if (dmabuf->ops->detach)
>>   		dmabuf->ops->detach(dmabuf, attach);
>>   
>> @@ -730,6 +806,44 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
>>   }
>>   EXPORT_SYMBOL_GPL(dma_buf_detach);
>>   
>> +/**
>> + * dma_buf_pin - Lock down the DMA-buf
>> + *
>> + * @attach:	[in]	attachment which should be pinned
>> + *
>> + * Returns:
>> + * 0 on success, negative error code on failure.
>> + */
>> +int dma_buf_pin(struct dma_buf_attachment *attach)
>> +{
>> +	struct dma_buf *dmabuf = attach->dmabuf;
>> +	int ret = 0;
>> +
>> +	reservation_object_assert_held(dmabuf->resv);
>> +
>> +	if (dmabuf->ops->pin)
>> +		ret = dmabuf->ops->pin(attach);
>> +
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_pin);
>> +
>> +/**
>> + * dma_buf_unpin - Remove lock from DMA-buf
>> + *
>> + * @attach:	[in]	attachment which should be unpinned
>> + */
>> +void dma_buf_unpin(struct dma_buf_attachment *attach)
>> +{
>> +	struct dma_buf *dmabuf = attach->dmabuf;
>> +
>> +	reservation_object_assert_held(dmabuf->resv);
>> +
>> +	if (dmabuf->ops->unpin)
>> +		dmabuf->ops->unpin(attach);
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_unpin);
>> +
>>   /**
>>    * dma_buf_map_attachment - Returns the scatterlist table of the attachment;
>>    * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
>> @@ -749,6 +863,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>>   					enum dma_data_direction direction)
>>   {
>>   	struct sg_table *sg_table;
>> +	int r;
>>   
>>   	might_sleep();
>>   
>> @@ -767,10 +882,29 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>>   		return attach->sgt;
>>   	}
>>   
>> +	if (dma_buf_attachment_is_dynamic(attach)) {
>> +		reservation_object_assert_held(attach->dmabuf->resv);
>> +
>> +	} else if (dma_buf_is_dynamic(attach->dmabuf)) {
>> +		reservation_object_lock(attach->dmabuf->resv, NULL);
>> +		r = dma_buf_pin(attach);
>> +		if (r) {
>> +			reservation_object_unlock(attach->dmabuf->resv);
>> +			return ERR_PTR(r);
>> +		}
>> +	}
> With this design (because we can't cache at attach time unconditionally)
> we inflict the reservation lock on all importers. So needs:
>
> 	} else {
> 		/* neither importer nor exporter are dynamice */
> 		might_lock(dmabuf->resv->ww_mutex);
> 	}
>
> Same for dma_buf_unmap_attachment.

Good idea.

>
> I also expect that this will blow up in intel-gfx-ci :-/ I did look at
> previous intel-gfx-ci runs of your series, and the last one that did pass
> was the one that still had the caching in _attach():

Well as far as I can see the current one passes as well. Actually just 
recently found a typo because of this.

>
> Geez I was sooooooooo locking forward to slapping an r-b on this and
> volunteering myself to polish the kerneldoc (which isn't great, but also
> pre-existing condition plus on my todo list anyway) :-(

Going to add the might_lock and send again, let's see what intel-gfx-ci 
has say to this.

Christian.

>
>> +
>>   	sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
>>   	if (!sg_table)
>>   		sg_table = ERR_PTR(-ENOMEM);
>>   
>> +	if (!dma_buf_attachment_is_dynamic(attach) &&
>> +	    dma_buf_is_dynamic(attach->dmabuf)) {
>> +		if (IS_ERR(sg_table))
>> +			dma_buf_unpin(attach);
>> +		reservation_object_unlock(attach->dmabuf->resv);
>> +	}
>> +
>>   	if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
>>   		attach->sgt = sg_table;
>>   		attach->dir = direction;
>> @@ -802,10 +936,41 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
>>   	if (attach->sgt == sg_table)
>>   		return;
>>   
>> +	if (dma_buf_attachment_is_dynamic(attach))
>> +		reservation_object_assert_held(attach->dmabuf->resv);
>> +	else if (dma_buf_is_dynamic(attach->dmabuf))
>> +		reservation_object_lock(attach->dmabuf->resv, NULL);
>> +
>>   	attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
>> +
>> +	if (dma_buf_is_dynamic(attach->dmabuf) &&
>> +	    !dma_buf_attachment_is_dynamic(attach)) {
>> +		dma_buf_unpin(attach);
>> +		reservation_object_unlock(attach->dmabuf->resv);
>> +	}
>>   }
>>   EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>>   
>> +/**
>> + * dma_buf_move_notify - notify attachments that DMA-buf is moving
>> + *
>> + * @dmabuf:	[in]	buffer which is moving
>> + *
>> + * Informs all attachmenst that they need to destroy and recreated all their
>> + * mappings.
>> + */
>> +void dma_buf_move_notify(struct dma_buf *dmabuf)
>> +{
>> +	struct dma_buf_attachment *attach;
>> +
>> +	reservation_object_assert_held(dmabuf->resv);
>> +
>> +	list_for_each_entry(attach, &dmabuf->attachments, node)
>> +		if (attach->importer_ops && attach->importer_ops->move_notify)
>> +			attach->importer_ops->move_notify(attach);
>> +}
>> +EXPORT_SYMBOL_GPL(dma_buf_move_notify);
>> +
>>   /**
>>    * DOC: cpu access
>>    *
>> @@ -1225,10 +1390,12 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
>>   		seq_puts(s, "\tAttached Devices:\n");
>>   		attach_count = 0;
>>   
>> +		reservation_object_lock(buf_obj->resv, NULL);
>>   		list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
>>   			seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
>>   			attach_count++;
>>   		}
>> +		reservation_object_unlock(buf_obj->resv);
> Yeah definitely time to retire dmabuf->lock I think.
>
> Cheers, Daniel
>
>>   
>>   		seq_printf(s, "Total %d devices attached\n\n",
>>   				attach_count);
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index 01ad5b942a6f..ccad2fc1f640 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -92,14 +92,40 @@ struct dma_buf_ops {
>>   	 */
>>   	void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
>>   
>> +	/**
>> +	 * @pin:
>> +	 *
>> +	 * This is called by dma_buf_pin and lets the exporter know that the
>> +	 * DMA-buf can't be moved any more.
>> +	 *
>> +	 * This is called with the dmabuf->resv object locked.
>> +	 *
>> +	 * This callback is optional.
>> +	 *
>> +	 * Returns:
>> +	 *
>> +	 * 0 on success, negative error code on failure.
>> +	 */
>> +	int (*pin)(struct dma_buf_attachment *attach);
>> +
>> +	/**
>> +	 * @unpin:
>> +	 *
>> +	 * This is called by dma_buf_unpin and lets the exporter know that the
>> +	 * DMA-buf can be moved again.
>> +	 *
>> +	 * This is called with the dmabuf->resv object locked.
>> +	 *
>> +	 * This callback is optional.
>> +	 */
>> +	void (*unpin)(struct dma_buf_attachment *attach);
>> +
>>   	/**
>>   	 * @map_dma_buf:
>>   	 *
>>   	 * This is called by dma_buf_map_attachment() and is used to map a
>>   	 * shared &dma_buf into device address space, and it is mandatory. It
>> -	 * can only be called if @attach has been called successfully. This
>> -	 * essentially pins the DMA buffer into place, and it cannot be moved
>> -	 * any more
>> +	 * can only be called if @attach has been called successfully.
>>   	 *
>>   	 * This call may sleep, e.g. when the backing storage first needs to be
>>   	 * allocated, or moved to a location suitable for all currently attached
>> @@ -120,6 +146,9 @@ struct dma_buf_ops {
>>   	 * any other kind of sharing that the exporter might wish to make
>>   	 * available to buffer-users.
>>   	 *
>> +	 * This is always called with the dmabuf->resv object locked when
>> +	 * the pin/unpin callbacks are implemented.
>> +	 *
>>   	 * Returns:
>>   	 *
>>   	 * A &sg_table scatter list of or the backing storage of the DMA buffer,
>> @@ -137,9 +166,6 @@ struct dma_buf_ops {
>>   	 *
>>   	 * This is called by dma_buf_unmap_attachment() and should unmap and
>>   	 * release the &sg_table allocated in @map_dma_buf, and it is mandatory.
>> -	 * It should also unpin the backing storage if this is the last mapping
>> -	 * of the DMA buffer, it the exporter supports backing storage
>> -	 * migration.
>>   	 */
>>   	void (*unmap_dma_buf)(struct dma_buf_attachment *,
>>   			      struct sg_table *,
>> @@ -330,6 +356,34 @@ struct dma_buf {
>>   	} cb_excl, cb_shared;
>>   };
>>   
>> +/**
>> + * struct dma_buf_attach_ops - importer operations for an attachment
>> + * @move_notify: [optional] notification that the DMA-buf is moving
>> + *
>> + * Attachment operations implemented by the importer.
>> + */
>> +struct dma_buf_attach_ops {
>> +	/**
>> +	 * @move_notify
>> +	 *
>> +	 * If this callback is provided the framework can avoid pinning the
>> +	 * backing store while mappings exists.
>> +	 *
>> +	 * This callback is called with the lock of the reservation object
>> +	 * associated with the dma_buf held and the mapping function must be
>> +	 * called with this lock held as well. This makes sure that no mapping
>> +	 * is created concurrently with an ongoing move operation.
>> +	 *
>> +	 * Mappings stay valid and are not directly affected by this callback.
>> +	 * But the DMA-buf can now be in a different physical location, so all
>> +	 * mappings should be destroyed and re-created as soon as possible.
>> +	 *
>> +	 * New mappings can be created after this callback returns, and will
>> +	 * point to the new location of the DMA-buf.
>> +	 */
>> +	void (*move_notify)(struct dma_buf_attachment *attach);
>> +};
>> +
>>   /**
>>    * struct dma_buf_attachment - holds device-buffer attachment data
>>    * @dmabuf: buffer for this attachment.
>> @@ -338,6 +392,8 @@ struct dma_buf {
>>    * @sgt: cached mapping.
>>    * @dir: direction of cached mapping.
>>    * @priv: exporter specific attachment data.
>> + * @importer_ops: importer operations for this attachment.
>> + * @importer_priv: importer specific attachment data.
>>    *
>>    * This structure holds the attachment information between the dma_buf buffer
>>    * and its user device(s). The list contains one attachment struct per device
>> @@ -355,6 +411,9 @@ struct dma_buf_attachment {
>>   	struct sg_table *sgt;
>>   	enum dma_data_direction dir;
>>   	void *priv;
>> +
>> +	const struct dma_buf_attach_ops *importer_ops;
>> +	void *importer_priv;
>>   };
>>   
>>   /**
>> @@ -405,10 +464,42 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
>>   	get_file(dmabuf->file);
>>   }
>>   
>> +/**
>> + * dma_buf_is_dynamic - check if a DMA-buf uses dynamic mappings.
>> + * @dmabuf: the DMA-buf to check
>> + *
>> + * Returns true if a DMA-buf exporter wants to create dynamic sg table mappings
>> + * for each attachment. False if only a single static sg table should be used.
>> + */
>> +static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
>> +{
>> +	return !!dmabuf->ops->pin;
>> +}
>> +
>> +/**
>> + * dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses dynamic
>> + * mappinsg
>> + * @attach: the DMA-buf attachment to check
>> + *
>> + * Returns true if a DMA-buf importer wants to use dynamic sg table mappings and
>> + * calls the map/unmap functions with the reservation object locked.
>> + */
>> +static inline bool
>> +dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
>> +{
>> +	return attach->importer_ops && attach->importer_ops->move_notify;
>> +}
>> +
>>   struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>> -							struct device *dev);
>> +					  struct device *dev);
>> +struct dma_buf_attachment *
>> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
>> +		       const struct dma_buf_attach_ops *importer_ops,
>> +		       void *importer_priv);
>>   void dma_buf_detach(struct dma_buf *dmabuf,
>> -				struct dma_buf_attachment *dmabuf_attach);
>> +		    struct dma_buf_attachment *attach);
>> +int dma_buf_pin(struct dma_buf_attachment *attach);
>> +void dma_buf_unpin(struct dma_buf_attachment *attach);
>>   
>>   struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
>>   
>> @@ -420,6 +511,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
>>   					enum dma_data_direction);
>>   void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
>>   				enum dma_data_direction);
>> +void dma_buf_move_notify(struct dma_buf *dma_buf);
>>   int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
>>   			     enum dma_data_direction dir);
>>   int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
>> -- 
>> 2.17.1
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Daniel Vetter]

On Tue, Jun 25, 2019 at 4:45 PM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> Am 25.06.19 um 16:35 schrieb Daniel Vetter:
> > Hi Christian,
> >
> > On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
> >> On the exporter side we add optional explicit pinning callbacks. If those
> >> callbacks are implemented the framework no longer caches sg tables and the
> >> map/unmap callbacks are always called with the lock of the reservation object
> >> held.
> >>
> >> On the importer side we add an optional invalidate callback. This callback is
> >> used by the exporter to inform the importers that their mappings should be
> >> destroyed as soon as possible.
> >>
> >> This allows the exporter to provide the mappings without the need to pin
> >> the backing store.
> >>
> >> v2: don't try to invalidate mappings when the callback is NULL,
> >>      lock the reservation obj while using the attachments,
> >>      add helper to set the callback
> >> v3: move flag for invalidation support into the DMA-buf,
> >>      use new attach_info structure to set the callback
> >> v4: use importer_priv field instead of mangling exporter priv.
> >> v5: drop invalidation_supported flag
> >> v6: squash together with pin/unpin changes
> >> v7: pin/unpin takes an attachment now
> >> v8: nuke dma_buf_attachment_(map|unmap)_locked,
> >>      everything is now handled backward compatible
> >> v9: always cache when export/importer don't agree on dynamic handling
> >> v10: minimal style cleanup
> >> v11: drop automatically re-entry avoidance
> >> v12: rename callback to move_notify
> >>
> >> Signed-off-by: Christian König <christian.koenig@amd.com>
> >> ---
> >>   drivers/dma-buf/dma-buf.c | 179 ++++++++++++++++++++++++++++++++++++--
> >>   include/linux/dma-buf.h   | 108 +++++++++++++++++++++--
> >>   2 files changed, 273 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >> index 6c15deb5d4ad..216f76109f3f 100644
> >> --- a/drivers/dma-buf/dma-buf.c
> >> +++ b/drivers/dma-buf/dma-buf.c
> >> @@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
> >>              return ERR_PTR(-EINVAL);
> >>      }
> >>
> >> +    if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
> >> +            return ERR_PTR(-EINVAL);
> >> +
> >>      if (!try_module_get(exp_info->owner))
> >>              return ERR_PTR(-ENOENT);
> >>
> >> @@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
> >>   EXPORT_SYMBOL_GPL(dma_buf_put);
> >>
> >>   /**
> >> - * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
> >> + * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list; optionally,
> >>    * calls attach() of dma_buf_ops to allow device-specific attach functionality
> >> - * @dmabuf: [in]    buffer to attach device to.
> >> - * @dev:    [in]    device to be attached.
> >> + * @dmabuf:         [in]    buffer to attach device to.
> >> + * @dev:            [in]    device to be attached.
> >> + * @importer_ops    [in]    importer operations for the attachment
> >> + * @importer_priv   [in]    importer private pointer for the attachment
> >>    *
> >>    * Returns struct dma_buf_attachment pointer for this attachment. Attachments
> >>    * must be cleaned up by calling dma_buf_detach().
> >> @@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> >>    * accessible to @dev, and cannot be moved to a more suitable place. This is
> >>    * indicated with the error code -EBUSY.
> >>    */
> >> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> >> -                                      struct device *dev)
> >> +struct dma_buf_attachment *
> >> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> >> +                   const struct dma_buf_attach_ops *importer_ops,
> >> +                   void *importer_priv)
> >>   {
> >>      struct dma_buf_attachment *attach;
> >>      int ret;
> >> @@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> >>
> >>      attach->dev = dev;
> >>      attach->dmabuf = dmabuf;
> >> +    attach->importer_ops = importer_ops;
> >> +    attach->importer_priv = importer_priv;
> >>
> >>      mutex_lock(&dmabuf->lock);
> >>
> >> @@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> >>              if (ret)
> >>                      goto err_attach;
> >>      }
> >> +    reservation_object_lock(dmabuf->resv, NULL);
> >>      list_add(&attach->node, &dmabuf->attachments);
> >> +    reservation_object_unlock(dmabuf->resv);
> >>
> >>      mutex_unlock(&dmabuf->lock);
> >>
> >> +    /* When either the importer or the exporter can't handle dynamic
> >> +     * mappings we cache the mapping here to avoid issues with the
> >> +     * reservation object lock.
> >> +     */
> >> +    if (dma_buf_attachment_is_dynamic(attach) !=
> >> +        dma_buf_is_dynamic(dmabuf)) {
> >> +            struct sg_table *sgt;
> >> +
> >> +            if (dma_buf_is_dynamic(attach->dmabuf)) {
> >> +                    reservation_object_lock(attach->dmabuf->resv, NULL);
> >> +                    ret = dma_buf_pin(attach);
> >> +                    if (ret)
> >> +                            goto err_unlock;
> >> +            }
> >> +
> >> +            sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> >> +            if (!sgt)
> >> +                    sgt = ERR_PTR(-ENOMEM);
> >> +            if (IS_ERR(sgt)) {
> >> +                    ret = PTR_ERR(sgt);
> >> +                    goto err_unpin;
> >> +            }
> >> +            if (dma_buf_is_dynamic(attach->dmabuf))
> >> +                    reservation_object_unlock(attach->dmabuf->resv);
> >> +            attach->sgt = sgt;
> >> +            attach->dir = DMA_BIDIRECTIONAL;
> >> +    }
> >> +
> >>      return attach;
> >>
> >>   err_attach:
> >>      kfree(attach);
> >>      mutex_unlock(&dmabuf->lock);
> >>      return ERR_PTR(ret);
> >> +
> >> +err_unpin:
> >> +    if (dma_buf_is_dynamic(attach->dmabuf))
> >> +            dma_buf_unpin(attach);
> >> +
> >> +err_unlock:
> >> +    if (dma_buf_is_dynamic(attach->dmabuf))
> >> +            reservation_object_unlock(attach->dmabuf->resv);
> >> +
> >> +    dma_buf_detach(dmabuf, attach);
> >> +    return ERR_PTR(ret);
> >> +}
> >> +EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
> >> +
> >> +/**
> >> + * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
> >> + * @dmabuf: [in]    buffer to attach device to.
> >> + * @dev:    [in]    device to be attached.
> >> + *
> >> + * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a static
> >> + * mapping.
> >> + */
> >> +struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> >> +                                      struct device *dev)
> >> +{
> >> +    return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
> >>   }
> >>   EXPORT_SYMBOL_GPL(dma_buf_attach);
> >>
> >> @@ -717,11 +782,22 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
> >>      if (WARN_ON(!dmabuf || !attach))
> >>              return;
> >>
> >> -    if (attach->sgt)
> >> +    if (attach->sgt) {
> >> +            if (dma_buf_is_dynamic(attach->dmabuf))
> >> +                    reservation_object_lock(attach->dmabuf->resv, NULL);
> >> +
> >>              dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir);
> >>
> >> +            if (dma_buf_is_dynamic(attach->dmabuf)) {
> >> +                    dma_buf_unpin(attach);
> >> +                    reservation_object_unlock(attach->dmabuf->resv);
> >> +            }
> >> +    }
> >> +
> >>      mutex_lock(&dmabuf->lock);
> > Time to ditch dmabuf->lock in favour of the reservation obj? We have a
> > fallback resv_obj in struct dma_buf already, so this is never null, and I
> > think would clean up the code a bit.
>
> Yeah, thought about that as well. But then decided against it for now.
>
> Key point is that exporters currently doesn't care about dmabuf->lock,
> but they do care about the reservation lock.
>
> So we will probably have a bunch of cases where we have to fix up
> exporters because they will try to grab the reservation lock as well.
>
> On the other hand we maybe not need a lock at all here if we just can
> live with multiple attach/detach callbacks running in parallel.

Well looking through the code I thought that all the places you grab
dmabuf->resv we also grab dmabuf->lock, so seemed fully redundant. But
I didn't check completely.

>
> >
> >
> >> +    reservation_object_lock(dmabuf->resv, NULL);
> >>      list_del(&attach->node);
> >> +    reservation_object_unlock(dmabuf->resv);
> >>      if (dmabuf->ops->detach)
> >>              dmabuf->ops->detach(dmabuf, attach);
> >>
> >> @@ -730,6 +806,44 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
> >>   }
> >>   EXPORT_SYMBOL_GPL(dma_buf_detach);
> >>
> >> +/**
> >> + * dma_buf_pin - Lock down the DMA-buf
> >> + *
> >> + * @attach: [in]    attachment which should be pinned
> >> + *
> >> + * Returns:
> >> + * 0 on success, negative error code on failure.
> >> + */
> >> +int dma_buf_pin(struct dma_buf_attachment *attach)
> >> +{
> >> +    struct dma_buf *dmabuf = attach->dmabuf;
> >> +    int ret = 0;
> >> +
> >> +    reservation_object_assert_held(dmabuf->resv);
> >> +
> >> +    if (dmabuf->ops->pin)
> >> +            ret = dmabuf->ops->pin(attach);
> >> +
> >> +    return ret;
> >> +}
> >> +EXPORT_SYMBOL_GPL(dma_buf_pin);
> >> +
> >> +/**
> >> + * dma_buf_unpin - Remove lock from DMA-buf
> >> + *
> >> + * @attach: [in]    attachment which should be unpinned
> >> + */
> >> +void dma_buf_unpin(struct dma_buf_attachment *attach)
> >> +{
> >> +    struct dma_buf *dmabuf = attach->dmabuf;
> >> +
> >> +    reservation_object_assert_held(dmabuf->resv);
> >> +
> >> +    if (dmabuf->ops->unpin)
> >> +            dmabuf->ops->unpin(attach);
> >> +}
> >> +EXPORT_SYMBOL_GPL(dma_buf_unpin);
> >> +
> >>   /**
> >>    * dma_buf_map_attachment - Returns the scatterlist table of the attachment;
> >>    * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
> >> @@ -749,6 +863,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
> >>                                      enum dma_data_direction direction)
> >>   {
> >>      struct sg_table *sg_table;
> >> +    int r;
> >>
> >>      might_sleep();
> >>
> >> @@ -767,10 +882,29 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
> >>              return attach->sgt;
> >>      }
> >>
> >> +    if (dma_buf_attachment_is_dynamic(attach)) {
> >> +            reservation_object_assert_held(attach->dmabuf->resv);
> >> +
> >> +    } else if (dma_buf_is_dynamic(attach->dmabuf)) {
> >> +            reservation_object_lock(attach->dmabuf->resv, NULL);
> >> +            r = dma_buf_pin(attach);
> >> +            if (r) {
> >> +                    reservation_object_unlock(attach->dmabuf->resv);
> >> +                    return ERR_PTR(r);
> >> +            }
> >> +    }
> > With this design (because we can't cache at attach time unconditionally)
> > we inflict the reservation lock on all importers. So needs:
> >
> >       } else {
> >               /* neither importer nor exporter are dynamice */
> >               might_lock(dmabuf->resv->ww_mutex);
> >       }
> >
> > Same for dma_buf_unmap_attachment.
>
> Good idea.
>
> >
> > I also expect that this will blow up in intel-gfx-ci :-/ I did look at
> > previous intel-gfx-ci runs of your series, and the last one that did pass
> > was the one that still had the caching in _attach():
>
> Well as far as I can see the current one passes as well. Actually just
> recently found a typo because of this.

Hm indeed the amd/i915 prime tests are still in BAT and that passed.
I'm surprised. Maybe Chris Wilson moved along quite a lot with our
locking rework and i915 isn't the bad one out anymore.

> > Geez I was sooooooooo locking forward to slapping an r-b on this and
> > volunteering myself to polish the kerneldoc (which isn't great, but also
> > pre-existing condition plus on my todo list anyway) :-(
>
> Going to add the might_lock and send again, let's see what intel-gfx-ci
> has say to this.

Yeah that should at least increase the chances we're seeing something.
Ofc intel-gfx-ci doesn't test everything :-)
-Daniel

>
> Christian.
>
> >
> >> +
> >>      sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> >>      if (!sg_table)
> >>              sg_table = ERR_PTR(-ENOMEM);
> >>
> >> +    if (!dma_buf_attachment_is_dynamic(attach) &&
> >> +        dma_buf_is_dynamic(attach->dmabuf)) {
> >> +            if (IS_ERR(sg_table))
> >> +                    dma_buf_unpin(attach);
> >> +            reservation_object_unlock(attach->dmabuf->resv);
> >> +    }
> >> +
> >>      if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
> >>              attach->sgt = sg_table;
> >>              attach->dir = direction;
> >> @@ -802,10 +936,41 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
> >>      if (attach->sgt == sg_table)
> >>              return;
> >>
> >> +    if (dma_buf_attachment_is_dynamic(attach))
> >> +            reservation_object_assert_held(attach->dmabuf->resv);
> >> +    else if (dma_buf_is_dynamic(attach->dmabuf))
> >> +            reservation_object_lock(attach->dmabuf->resv, NULL);
> >> +
> >>      attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
> >> +
> >> +    if (dma_buf_is_dynamic(attach->dmabuf) &&
> >> +        !dma_buf_attachment_is_dynamic(attach)) {
> >> +            dma_buf_unpin(attach);
> >> +            reservation_object_unlock(attach->dmabuf->resv);
> >> +    }
> >>   }
> >>   EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> >>
> >> +/**
> >> + * dma_buf_move_notify - notify attachments that DMA-buf is moving
> >> + *
> >> + * @dmabuf: [in]    buffer which is moving
> >> + *
> >> + * Informs all attachmenst that they need to destroy and recreated all their
> >> + * mappings.
> >> + */
> >> +void dma_buf_move_notify(struct dma_buf *dmabuf)
> >> +{
> >> +    struct dma_buf_attachment *attach;
> >> +
> >> +    reservation_object_assert_held(dmabuf->resv);
> >> +
> >> +    list_for_each_entry(attach, &dmabuf->attachments, node)
> >> +            if (attach->importer_ops && attach->importer_ops->move_notify)
> >> +                    attach->importer_ops->move_notify(attach);
> >> +}
> >> +EXPORT_SYMBOL_GPL(dma_buf_move_notify);
> >> +
> >>   /**
> >>    * DOC: cpu access
> >>    *
> >> @@ -1225,10 +1390,12 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
> >>              seq_puts(s, "\tAttached Devices:\n");
> >>              attach_count = 0;
> >>
> >> +            reservation_object_lock(buf_obj->resv, NULL);
> >>              list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
> >>                      seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
> >>                      attach_count++;
> >>              }
> >> +            reservation_object_unlock(buf_obj->resv);
> > Yeah definitely time to retire dmabuf->lock I think.
> >
> > Cheers, Daniel
> >
> >>
> >>              seq_printf(s, "Total %d devices attached\n\n",
> >>                              attach_count);
> >> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> >> index 01ad5b942a6f..ccad2fc1f640 100644
> >> --- a/include/linux/dma-buf.h
> >> +++ b/include/linux/dma-buf.h
> >> @@ -92,14 +92,40 @@ struct dma_buf_ops {
> >>       */
> >>      void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
> >>
> >> +    /**
> >> +     * @pin:
> >> +     *
> >> +     * This is called by dma_buf_pin and lets the exporter know that the
> >> +     * DMA-buf can't be moved any more.
> >> +     *
> >> +     * This is called with the dmabuf->resv object locked.
> >> +     *
> >> +     * This callback is optional.
> >> +     *
> >> +     * Returns:
> >> +     *
> >> +     * 0 on success, negative error code on failure.
> >> +     */
> >> +    int (*pin)(struct dma_buf_attachment *attach);
> >> +
> >> +    /**
> >> +     * @unpin:
> >> +     *
> >> +     * This is called by dma_buf_unpin and lets the exporter know that the
> >> +     * DMA-buf can be moved again.
> >> +     *
> >> +     * This is called with the dmabuf->resv object locked.
> >> +     *
> >> +     * This callback is optional.
> >> +     */
> >> +    void (*unpin)(struct dma_buf_attachment *attach);
> >> +
> >>      /**
> >>       * @map_dma_buf:
> >>       *
> >>       * This is called by dma_buf_map_attachment() and is used to map a
> >>       * shared &dma_buf into device address space, and it is mandatory. It
> >> -     * can only be called if @attach has been called successfully. This
> >> -     * essentially pins the DMA buffer into place, and it cannot be moved
> >> -     * any more
> >> +     * can only be called if @attach has been called successfully.
> >>       *
> >>       * This call may sleep, e.g. when the backing storage first needs to be
> >>       * allocated, or moved to a location suitable for all currently attached
> >> @@ -120,6 +146,9 @@ struct dma_buf_ops {
> >>       * any other kind of sharing that the exporter might wish to make
> >>       * available to buffer-users.
> >>       *
> >> +     * This is always called with the dmabuf->resv object locked when
> >> +     * the pin/unpin callbacks are implemented.
> >> +     *
> >>       * Returns:
> >>       *
> >>       * A &sg_table scatter list of or the backing storage of the DMA buffer,
> >> @@ -137,9 +166,6 @@ struct dma_buf_ops {
> >>       *
> >>       * This is called by dma_buf_unmap_attachment() and should unmap and
> >>       * release the &sg_table allocated in @map_dma_buf, and it is mandatory.
> >> -     * It should also unpin the backing storage if this is the last mapping
> >> -     * of the DMA buffer, it the exporter supports backing storage
> >> -     * migration.
> >>       */
> >>      void (*unmap_dma_buf)(struct dma_buf_attachment *,
> >>                            struct sg_table *,
> >> @@ -330,6 +356,34 @@ struct dma_buf {
> >>      } cb_excl, cb_shared;
> >>   };
> >>
> >> +/**
> >> + * struct dma_buf_attach_ops - importer operations for an attachment
> >> + * @move_notify: [optional] notification that the DMA-buf is moving
> >> + *
> >> + * Attachment operations implemented by the importer.
> >> + */
> >> +struct dma_buf_attach_ops {
> >> +    /**
> >> +     * @move_notify
> >> +     *
> >> +     * If this callback is provided the framework can avoid pinning the
> >> +     * backing store while mappings exists.
> >> +     *
> >> +     * This callback is called with the lock of the reservation object
> >> +     * associated with the dma_buf held and the mapping function must be
> >> +     * called with this lock held as well. This makes sure that no mapping
> >> +     * is created concurrently with an ongoing move operation.
> >> +     *
> >> +     * Mappings stay valid and are not directly affected by this callback.
> >> +     * But the DMA-buf can now be in a different physical location, so all
> >> +     * mappings should be destroyed and re-created as soon as possible.
> >> +     *
> >> +     * New mappings can be created after this callback returns, and will
> >> +     * point to the new location of the DMA-buf.
> >> +     */
> >> +    void (*move_notify)(struct dma_buf_attachment *attach);
> >> +};
> >> +
> >>   /**
> >>    * struct dma_buf_attachment - holds device-buffer attachment data
> >>    * @dmabuf: buffer for this attachment.
> >> @@ -338,6 +392,8 @@ struct dma_buf {
> >>    * @sgt: cached mapping.
> >>    * @dir: direction of cached mapping.
> >>    * @priv: exporter specific attachment data.
> >> + * @importer_ops: importer operations for this attachment.
> >> + * @importer_priv: importer specific attachment data.
> >>    *
> >>    * This structure holds the attachment information between the dma_buf buffer
> >>    * and its user device(s). The list contains one attachment struct per device
> >> @@ -355,6 +411,9 @@ struct dma_buf_attachment {
> >>      struct sg_table *sgt;
> >>      enum dma_data_direction dir;
> >>      void *priv;
> >> +
> >> +    const struct dma_buf_attach_ops *importer_ops;
> >> +    void *importer_priv;
> >>   };
> >>
> >>   /**
> >> @@ -405,10 +464,42 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
> >>      get_file(dmabuf->file);
> >>   }
> >>
> >> +/**
> >> + * dma_buf_is_dynamic - check if a DMA-buf uses dynamic mappings.
> >> + * @dmabuf: the DMA-buf to check
> >> + *
> >> + * Returns true if a DMA-buf exporter wants to create dynamic sg table mappings
> >> + * for each attachment. False if only a single static sg table should be used.
> >> + */
> >> +static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
> >> +{
> >> +    return !!dmabuf->ops->pin;
> >> +}
> >> +
> >> +/**
> >> + * dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses dynamic
> >> + * mappinsg
> >> + * @attach: the DMA-buf attachment to check
> >> + *
> >> + * Returns true if a DMA-buf importer wants to use dynamic sg table mappings and
> >> + * calls the map/unmap functions with the reservation object locked.
> >> + */
> >> +static inline bool
> >> +dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
> >> +{
> >> +    return attach->importer_ops && attach->importer_ops->move_notify;
> >> +}
> >> +
> >>   struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> >> -                                                    struct device *dev);
> >> +                                      struct device *dev);
> >> +struct dma_buf_attachment *
> >> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> >> +                   const struct dma_buf_attach_ops *importer_ops,
> >> +                   void *importer_priv);
> >>   void dma_buf_detach(struct dma_buf *dmabuf,
> >> -                            struct dma_buf_attachment *dmabuf_attach);
> >> +                struct dma_buf_attachment *attach);
> >> +int dma_buf_pin(struct dma_buf_attachment *attach);
> >> +void dma_buf_unpin(struct dma_buf_attachment *attach);
> >>
> >>   struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
> >>
> >> @@ -420,6 +511,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
> >>                                      enum dma_data_direction);
> >>   void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
> >>                              enum dma_data_direction);
> >> +void dma_buf_move_notify(struct dma_buf *dma_buf);
> >>   int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
> >>                           enum dma_data_direction dir);
> >>   int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
> >> --
> >> 2.17.1
> >>
> >> _______________________________________________
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Christian König]

Am 25.06.19 um 17:07 schrieb Daniel Vetter:
> On Tue, Jun 25, 2019 at 4:45 PM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>> Am 25.06.19 um 16:35 schrieb Daniel Vetter:
>>> Hi Christian,
>>>
>>> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
>>>> On the exporter side we add optional explicit pinning callbacks. If those
>>>> callbacks are implemented the framework no longer caches sg tables and the
>>>> map/unmap callbacks are always called with the lock of the reservation object
>>>> held.
>>>>
>>>> On the importer side we add an optional invalidate callback. This callback is
>>>> used by the exporter to inform the importers that their mappings should be
>>>> destroyed as soon as possible.
>>>>
>>>> This allows the exporter to provide the mappings without the need to pin
>>>> the backing store.
>>>>
>>>> v2: don't try to invalidate mappings when the callback is NULL,
>>>>       lock the reservation obj while using the attachments,
>>>>       add helper to set the callback
>>>> v3: move flag for invalidation support into the DMA-buf,
>>>>       use new attach_info structure to set the callback
>>>> v4: use importer_priv field instead of mangling exporter priv.
>>>> v5: drop invalidation_supported flag
>>>> v6: squash together with pin/unpin changes
>>>> v7: pin/unpin takes an attachment now
>>>> v8: nuke dma_buf_attachment_(map|unmap)_locked,
>>>>       everything is now handled backward compatible
>>>> v9: always cache when export/importer don't agree on dynamic handling
>>>> v10: minimal style cleanup
>>>> v11: drop automatically re-entry avoidance
>>>> v12: rename callback to move_notify
>>>>
>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>> ---
>>>>    drivers/dma-buf/dma-buf.c | 179 ++++++++++++++++++++++++++++++++++++--
>>>>    include/linux/dma-buf.h   | 108 +++++++++++++++++++++--
>>>>    2 files changed, 273 insertions(+), 14 deletions(-)
>>>>
>>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>>> index 6c15deb5d4ad..216f76109f3f 100644
>>>> --- a/drivers/dma-buf/dma-buf.c
>>>> +++ b/drivers/dma-buf/dma-buf.c
>>>> @@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
>>>>               return ERR_PTR(-EINVAL);
>>>>       }
>>>>
>>>> +    if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
>>>> +            return ERR_PTR(-EINVAL);
>>>> +
>>>>       if (!try_module_get(exp_info->owner))
>>>>               return ERR_PTR(-ENOENT);
>>>>
>>>> @@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
>>>>    EXPORT_SYMBOL_GPL(dma_buf_put);
>>>>
>>>>    /**
>>>> - * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
>>>> + * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list; optionally,
>>>>     * calls attach() of dma_buf_ops to allow device-specific attach functionality
>>>> - * @dmabuf: [in]    buffer to attach device to.
>>>> - * @dev:    [in]    device to be attached.
>>>> + * @dmabuf:         [in]    buffer to attach device to.
>>>> + * @dev:            [in]    device to be attached.
>>>> + * @importer_ops    [in]    importer operations for the attachment
>>>> + * @importer_priv   [in]    importer private pointer for the attachment
>>>>     *
>>>>     * Returns struct dma_buf_attachment pointer for this attachment. Attachments
>>>>     * must be cleaned up by calling dma_buf_detach().
>>>> @@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
>>>>     * accessible to @dev, and cannot be moved to a more suitable place. This is
>>>>     * indicated with the error code -EBUSY.
>>>>     */
>>>> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>>>> -                                      struct device *dev)
>>>> +struct dma_buf_attachment *
>>>> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
>>>> +                   const struct dma_buf_attach_ops *importer_ops,
>>>> +                   void *importer_priv)
>>>>    {
>>>>       struct dma_buf_attachment *attach;
>>>>       int ret;
>>>> @@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>>>>
>>>>       attach->dev = dev;
>>>>       attach->dmabuf = dmabuf;
>>>> +    attach->importer_ops = importer_ops;
>>>> +    attach->importer_priv = importer_priv;
>>>>
>>>>       mutex_lock(&dmabuf->lock);
>>>>
>>>> @@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>>>>               if (ret)
>>>>                       goto err_attach;
>>>>       }
>>>> +    reservation_object_lock(dmabuf->resv, NULL);
>>>>       list_add(&attach->node, &dmabuf->attachments);
>>>> +    reservation_object_unlock(dmabuf->resv);
>>>>
>>>>       mutex_unlock(&dmabuf->lock);
>>>>
>>>> +    /* When either the importer or the exporter can't handle dynamic
>>>> +     * mappings we cache the mapping here to avoid issues with the
>>>> +     * reservation object lock.
>>>> +     */
>>>> +    if (dma_buf_attachment_is_dynamic(attach) !=
>>>> +        dma_buf_is_dynamic(dmabuf)) {
>>>> +            struct sg_table *sgt;
>>>> +
>>>> +            if (dma_buf_is_dynamic(attach->dmabuf)) {
>>>> +                    reservation_object_lock(attach->dmabuf->resv, NULL);
>>>> +                    ret = dma_buf_pin(attach);
>>>> +                    if (ret)
>>>> +                            goto err_unlock;
>>>> +            }
>>>> +
>>>> +            sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
>>>> +            if (!sgt)
>>>> +                    sgt = ERR_PTR(-ENOMEM);
>>>> +            if (IS_ERR(sgt)) {
>>>> +                    ret = PTR_ERR(sgt);
>>>> +                    goto err_unpin;
>>>> +            }
>>>> +            if (dma_buf_is_dynamic(attach->dmabuf))
>>>> +                    reservation_object_unlock(attach->dmabuf->resv);
>>>> +            attach->sgt = sgt;
>>>> +            attach->dir = DMA_BIDIRECTIONAL;
>>>> +    }
>>>> +
>>>>       return attach;
>>>>
>>>>    err_attach:
>>>>       kfree(attach);
>>>>       mutex_unlock(&dmabuf->lock);
>>>>       return ERR_PTR(ret);
>>>> +
>>>> +err_unpin:
>>>> +    if (dma_buf_is_dynamic(attach->dmabuf))
>>>> +            dma_buf_unpin(attach);
>>>> +
>>>> +err_unlock:
>>>> +    if (dma_buf_is_dynamic(attach->dmabuf))
>>>> +            reservation_object_unlock(attach->dmabuf->resv);
>>>> +
>>>> +    dma_buf_detach(dmabuf, attach);
>>>> +    return ERR_PTR(ret);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
>>>> +
>>>> +/**
>>>> + * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
>>>> + * @dmabuf: [in]    buffer to attach device to.
>>>> + * @dev:    [in]    device to be attached.
>>>> + *
>>>> + * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a static
>>>> + * mapping.
>>>> + */
>>>> +struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>>>> +                                      struct device *dev)
>>>> +{
>>>> +    return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
>>>>    }
>>>>    EXPORT_SYMBOL_GPL(dma_buf_attach);
>>>>
>>>> @@ -717,11 +782,22 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
>>>>       if (WARN_ON(!dmabuf || !attach))
>>>>               return;
>>>>
>>>> -    if (attach->sgt)
>>>> +    if (attach->sgt) {
>>>> +            if (dma_buf_is_dynamic(attach->dmabuf))
>>>> +                    reservation_object_lock(attach->dmabuf->resv, NULL);
>>>> +
>>>>               dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir);
>>>>
>>>> +            if (dma_buf_is_dynamic(attach->dmabuf)) {
>>>> +                    dma_buf_unpin(attach);
>>>> +                    reservation_object_unlock(attach->dmabuf->resv);
>>>> +            }
>>>> +    }
>>>> +
>>>>       mutex_lock(&dmabuf->lock);
>>> Time to ditch dmabuf->lock in favour of the reservation obj? We have a
>>> fallback resv_obj in struct dma_buf already, so this is never null, and I
>>> think would clean up the code a bit.
>> Yeah, thought about that as well. But then decided against it for now.
>>
>> Key point is that exporters currently doesn't care about dmabuf->lock,
>> but they do care about the reservation lock.
>>
>> So we will probably have a bunch of cases where we have to fix up
>> exporters because they will try to grab the reservation lock as well.
>>
>> On the other hand we maybe not need a lock at all here if we just can
>> live with multiple attach/detach callbacks running in parallel.
> Well looking through the code I thought that all the places you grab
> dmabuf->resv we also grab dmabuf->lock, so seemed fully redundant. But
> I didn't check completely.

The difference is that I didn't call attach/detach with the lock held yet.

And we could actually drop locking the reservation object while 
manipulating the list of attachments since we no longer use that workaround.

Going to fix that up tomorrow as well,
Christian.

>
>>>
>>>> +    reservation_object_lock(dmabuf->resv, NULL);
>>>>       list_del(&attach->node);
>>>> +    reservation_object_unlock(dmabuf->resv);
>>>>       if (dmabuf->ops->detach)
>>>>               dmabuf->ops->detach(dmabuf, attach);
>>>>
>>>> @@ -730,6 +806,44 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
>>>>    }
>>>>    EXPORT_SYMBOL_GPL(dma_buf_detach);
>>>>
>>>> +/**
>>>> + * dma_buf_pin - Lock down the DMA-buf
>>>> + *
>>>> + * @attach: [in]    attachment which should be pinned
>>>> + *
>>>> + * Returns:
>>>> + * 0 on success, negative error code on failure.
>>>> + */
>>>> +int dma_buf_pin(struct dma_buf_attachment *attach)
>>>> +{
>>>> +    struct dma_buf *dmabuf = attach->dmabuf;
>>>> +    int ret = 0;
>>>> +
>>>> +    reservation_object_assert_held(dmabuf->resv);
>>>> +
>>>> +    if (dmabuf->ops->pin)
>>>> +            ret = dmabuf->ops->pin(attach);
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(dma_buf_pin);
>>>> +
>>>> +/**
>>>> + * dma_buf_unpin - Remove lock from DMA-buf
>>>> + *
>>>> + * @attach: [in]    attachment which should be unpinned
>>>> + */
>>>> +void dma_buf_unpin(struct dma_buf_attachment *attach)
>>>> +{
>>>> +    struct dma_buf *dmabuf = attach->dmabuf;
>>>> +
>>>> +    reservation_object_assert_held(dmabuf->resv);
>>>> +
>>>> +    if (dmabuf->ops->unpin)
>>>> +            dmabuf->ops->unpin(attach);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(dma_buf_unpin);
>>>> +
>>>>    /**
>>>>     * dma_buf_map_attachment - Returns the scatterlist table of the attachment;
>>>>     * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
>>>> @@ -749,6 +863,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>>>>                                       enum dma_data_direction direction)
>>>>    {
>>>>       struct sg_table *sg_table;
>>>> +    int r;
>>>>
>>>>       might_sleep();
>>>>
>>>> @@ -767,10 +882,29 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>>>>               return attach->sgt;
>>>>       }
>>>>
>>>> +    if (dma_buf_attachment_is_dynamic(attach)) {
>>>> +            reservation_object_assert_held(attach->dmabuf->resv);
>>>> +
>>>> +    } else if (dma_buf_is_dynamic(attach->dmabuf)) {
>>>> +            reservation_object_lock(attach->dmabuf->resv, NULL);
>>>> +            r = dma_buf_pin(attach);
>>>> +            if (r) {
>>>> +                    reservation_object_unlock(attach->dmabuf->resv);
>>>> +                    return ERR_PTR(r);
>>>> +            }
>>>> +    }
>>> With this design (because we can't cache at attach time unconditionally)
>>> we inflict the reservation lock on all importers. So needs:
>>>
>>>        } else {
>>>                /* neither importer nor exporter are dynamice */
>>>                might_lock(dmabuf->resv->ww_mutex);
>>>        }
>>>
>>> Same for dma_buf_unmap_attachment.
>> Good idea.
>>
>>> I also expect that this will blow up in intel-gfx-ci :-/ I did look at
>>> previous intel-gfx-ci runs of your series, and the last one that did pass
>>> was the one that still had the caching in _attach():
>> Well as far as I can see the current one passes as well. Actually just
>> recently found a typo because of this.
> Hm indeed the amd/i915 prime tests are still in BAT and that passed.
> I'm surprised. Maybe Chris Wilson moved along quite a lot with our
> locking rework and i915 isn't the bad one out anymore.
>
>>> Geez I was sooooooooo locking forward to slapping an r-b on this and
>>> volunteering myself to polish the kerneldoc (which isn't great, but also
>>> pre-existing condition plus on my todo list anyway) :-(
>> Going to add the might_lock and send again, let's see what intel-gfx-ci
>> has say to this.
> Yeah that should at least increase the chances we're seeing something.
> Ofc intel-gfx-ci doesn't test everything :-)
> -Daniel
>
>> Christian.
>>
>>>> +
>>>>       sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
>>>>       if (!sg_table)
>>>>               sg_table = ERR_PTR(-ENOMEM);
>>>>
>>>> +    if (!dma_buf_attachment_is_dynamic(attach) &&
>>>> +        dma_buf_is_dynamic(attach->dmabuf)) {
>>>> +            if (IS_ERR(sg_table))
>>>> +                    dma_buf_unpin(attach);
>>>> +            reservation_object_unlock(attach->dmabuf->resv);
>>>> +    }
>>>> +
>>>>       if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
>>>>               attach->sgt = sg_table;
>>>>               attach->dir = direction;
>>>> @@ -802,10 +936,41 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
>>>>       if (attach->sgt == sg_table)
>>>>               return;
>>>>
>>>> +    if (dma_buf_attachment_is_dynamic(attach))
>>>> +            reservation_object_assert_held(attach->dmabuf->resv);
>>>> +    else if (dma_buf_is_dynamic(attach->dmabuf))
>>>> +            reservation_object_lock(attach->dmabuf->resv, NULL);
>>>> +
>>>>       attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
>>>> +
>>>> +    if (dma_buf_is_dynamic(attach->dmabuf) &&
>>>> +        !dma_buf_attachment_is_dynamic(attach)) {
>>>> +            dma_buf_unpin(attach);
>>>> +            reservation_object_unlock(attach->dmabuf->resv);
>>>> +    }
>>>>    }
>>>>    EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>>>>
>>>> +/**
>>>> + * dma_buf_move_notify - notify attachments that DMA-buf is moving
>>>> + *
>>>> + * @dmabuf: [in]    buffer which is moving
>>>> + *
>>>> + * Informs all attachmenst that they need to destroy and recreated all their
>>>> + * mappings.
>>>> + */
>>>> +void dma_buf_move_notify(struct dma_buf *dmabuf)
>>>> +{
>>>> +    struct dma_buf_attachment *attach;
>>>> +
>>>> +    reservation_object_assert_held(dmabuf->resv);
>>>> +
>>>> +    list_for_each_entry(attach, &dmabuf->attachments, node)
>>>> +            if (attach->importer_ops && attach->importer_ops->move_notify)
>>>> +                    attach->importer_ops->move_notify(attach);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(dma_buf_move_notify);
>>>> +
>>>>    /**
>>>>     * DOC: cpu access
>>>>     *
>>>> @@ -1225,10 +1390,12 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
>>>>               seq_puts(s, "\tAttached Devices:\n");
>>>>               attach_count = 0;
>>>>
>>>> +            reservation_object_lock(buf_obj->resv, NULL);
>>>>               list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
>>>>                       seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
>>>>                       attach_count++;
>>>>               }
>>>> +            reservation_object_unlock(buf_obj->resv);
>>> Yeah definitely time to retire dmabuf->lock I think.
>>>
>>> Cheers, Daniel
>>>
>>>>               seq_printf(s, "Total %d devices attached\n\n",
>>>>                               attach_count);
>>>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>>>> index 01ad5b942a6f..ccad2fc1f640 100644
>>>> --- a/include/linux/dma-buf.h
>>>> +++ b/include/linux/dma-buf.h
>>>> @@ -92,14 +92,40 @@ struct dma_buf_ops {
>>>>        */
>>>>       void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
>>>>
>>>> +    /**
>>>> +     * @pin:
>>>> +     *
>>>> +     * This is called by dma_buf_pin and lets the exporter know that the
>>>> +     * DMA-buf can't be moved any more.
>>>> +     *
>>>> +     * This is called with the dmabuf->resv object locked.
>>>> +     *
>>>> +     * This callback is optional.
>>>> +     *
>>>> +     * Returns:
>>>> +     *
>>>> +     * 0 on success, negative error code on failure.
>>>> +     */
>>>> +    int (*pin)(struct dma_buf_attachment *attach);
>>>> +
>>>> +    /**
>>>> +     * @unpin:
>>>> +     *
>>>> +     * This is called by dma_buf_unpin and lets the exporter know that the
>>>> +     * DMA-buf can be moved again.
>>>> +     *
>>>> +     * This is called with the dmabuf->resv object locked.
>>>> +     *
>>>> +     * This callback is optional.
>>>> +     */
>>>> +    void (*unpin)(struct dma_buf_attachment *attach);
>>>> +
>>>>       /**
>>>>        * @map_dma_buf:
>>>>        *
>>>>        * This is called by dma_buf_map_attachment() and is used to map a
>>>>        * shared &dma_buf into device address space, and it is mandatory. It
>>>> -     * can only be called if @attach has been called successfully. This
>>>> -     * essentially pins the DMA buffer into place, and it cannot be moved
>>>> -     * any more
>>>> +     * can only be called if @attach has been called successfully.
>>>>        *
>>>>        * This call may sleep, e.g. when the backing storage first needs to be
>>>>        * allocated, or moved to a location suitable for all currently attached
>>>> @@ -120,6 +146,9 @@ struct dma_buf_ops {
>>>>        * any other kind of sharing that the exporter might wish to make
>>>>        * available to buffer-users.
>>>>        *
>>>> +     * This is always called with the dmabuf->resv object locked when
>>>> +     * the pin/unpin callbacks are implemented.
>>>> +     *
>>>>        * Returns:
>>>>        *
>>>>        * A &sg_table scatter list of or the backing storage of the DMA buffer,
>>>> @@ -137,9 +166,6 @@ struct dma_buf_ops {
>>>>        *
>>>>        * This is called by dma_buf_unmap_attachment() and should unmap and
>>>>        * release the &sg_table allocated in @map_dma_buf, and it is mandatory.
>>>> -     * It should also unpin the backing storage if this is the last mapping
>>>> -     * of the DMA buffer, it the exporter supports backing storage
>>>> -     * migration.
>>>>        */
>>>>       void (*unmap_dma_buf)(struct dma_buf_attachment *,
>>>>                             struct sg_table *,
>>>> @@ -330,6 +356,34 @@ struct dma_buf {
>>>>       } cb_excl, cb_shared;
>>>>    };
>>>>
>>>> +/**
>>>> + * struct dma_buf_attach_ops - importer operations for an attachment
>>>> + * @move_notify: [optional] notification that the DMA-buf is moving
>>>> + *
>>>> + * Attachment operations implemented by the importer.
>>>> + */
>>>> +struct dma_buf_attach_ops {
>>>> +    /**
>>>> +     * @move_notify
>>>> +     *
>>>> +     * If this callback is provided the framework can avoid pinning the
>>>> +     * backing store while mappings exists.
>>>> +     *
>>>> +     * This callback is called with the lock of the reservation object
>>>> +     * associated with the dma_buf held and the mapping function must be
>>>> +     * called with this lock held as well. This makes sure that no mapping
>>>> +     * is created concurrently with an ongoing move operation.
>>>> +     *
>>>> +     * Mappings stay valid and are not directly affected by this callback.
>>>> +     * But the DMA-buf can now be in a different physical location, so all
>>>> +     * mappings should be destroyed and re-created as soon as possible.
>>>> +     *
>>>> +     * New mappings can be created after this callback returns, and will
>>>> +     * point to the new location of the DMA-buf.
>>>> +     */
>>>> +    void (*move_notify)(struct dma_buf_attachment *attach);
>>>> +};
>>>> +
>>>>    /**
>>>>     * struct dma_buf_attachment - holds device-buffer attachment data
>>>>     * @dmabuf: buffer for this attachment.
>>>> @@ -338,6 +392,8 @@ struct dma_buf {
>>>>     * @sgt: cached mapping.
>>>>     * @dir: direction of cached mapping.
>>>>     * @priv: exporter specific attachment data.
>>>> + * @importer_ops: importer operations for this attachment.
>>>> + * @importer_priv: importer specific attachment data.
>>>>     *
>>>>     * This structure holds the attachment information between the dma_buf buffer
>>>>     * and its user device(s). The list contains one attachment struct per device
>>>> @@ -355,6 +411,9 @@ struct dma_buf_attachment {
>>>>       struct sg_table *sgt;
>>>>       enum dma_data_direction dir;
>>>>       void *priv;
>>>> +
>>>> +    const struct dma_buf_attach_ops *importer_ops;
>>>> +    void *importer_priv;
>>>>    };
>>>>
>>>>    /**
>>>> @@ -405,10 +464,42 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
>>>>       get_file(dmabuf->file);
>>>>    }
>>>>
>>>> +/**
>>>> + * dma_buf_is_dynamic - check if a DMA-buf uses dynamic mappings.
>>>> + * @dmabuf: the DMA-buf to check
>>>> + *
>>>> + * Returns true if a DMA-buf exporter wants to create dynamic sg table mappings
>>>> + * for each attachment. False if only a single static sg table should be used.
>>>> + */
>>>> +static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
>>>> +{
>>>> +    return !!dmabuf->ops->pin;
>>>> +}
>>>> +
>>>> +/**
>>>> + * dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses dynamic
>>>> + * mappinsg
>>>> + * @attach: the DMA-buf attachment to check
>>>> + *
>>>> + * Returns true if a DMA-buf importer wants to use dynamic sg table mappings and
>>>> + * calls the map/unmap functions with the reservation object locked.
>>>> + */
>>>> +static inline bool
>>>> +dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
>>>> +{
>>>> +    return attach->importer_ops && attach->importer_ops->move_notify;
>>>> +}
>>>> +
>>>>    struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>>>> -                                                    struct device *dev);
>>>> +                                      struct device *dev);
>>>> +struct dma_buf_attachment *
>>>> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
>>>> +                   const struct dma_buf_attach_ops *importer_ops,
>>>> +                   void *importer_priv);
>>>>    void dma_buf_detach(struct dma_buf *dmabuf,
>>>> -                            struct dma_buf_attachment *dmabuf_attach);
>>>> +                struct dma_buf_attachment *attach);
>>>> +int dma_buf_pin(struct dma_buf_attachment *attach);
>>>> +void dma_buf_unpin(struct dma_buf_attachment *attach);
>>>>
>>>>    struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
>>>>
>>>> @@ -420,6 +511,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
>>>>                                       enum dma_data_direction);
>>>>    void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
>>>>                               enum dma_data_direction);
>>>> +void dma_buf_move_notify(struct dma_buf *dma_buf);
>>>>    int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
>>>>                            enum dma_data_direction dir);
>>>>    int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
>>>> --
>>>> 2.17.1
>>>>
>>>> _______________________________________________
>>>> Intel-gfx mailing list
>>>> Intel-gfx@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Daniel Vetter]

On Tue, Jun 25, 2019 at 05:13:42PM +0200, Christian König wrote:
> Am 25.06.19 um 17:07 schrieb Daniel Vetter:
> > On Tue, Jun 25, 2019 at 4:45 PM Christian König
> > <ckoenig.leichtzumerken@gmail.com> wrote:
> > > > > -    if (attach->sgt)
> > > > > +    if (attach->sgt) {
> > > > > +            if (dma_buf_is_dynamic(attach->dmabuf))
> > > > > +                    reservation_object_lock(attach->dmabuf->resv, NULL);
> > > > > +
> > > > >               dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir);
> > > > > 
> > > > > +            if (dma_buf_is_dynamic(attach->dmabuf)) {
> > > > > +                    dma_buf_unpin(attach);
> > > > > +                    reservation_object_unlock(attach->dmabuf->resv);
> > > > > +            }
> > > > > +    }
> > > > > +
> > > > >       mutex_lock(&dmabuf->lock);
> > > > Time to ditch dmabuf->lock in favour of the reservation obj? We have a
> > > > fallback resv_obj in struct dma_buf already, so this is never null, and I
> > > > think would clean up the code a bit.
> > > Yeah, thought about that as well. But then decided against it for now.
> > > 
> > > Key point is that exporters currently doesn't care about dmabuf->lock,
> > > but they do care about the reservation lock.
> > > 
> > > So we will probably have a bunch of cases where we have to fix up
> > > exporters because they will try to grab the reservation lock as well.
> > > 
> > > On the other hand we maybe not need a lock at all here if we just can
> > > live with multiple attach/detach callbacks running in parallel.
> > Well looking through the code I thought that all the places you grab
> > dmabuf->resv we also grab dmabuf->lock, so seemed fully redundant. But
> > I didn't check completely.
> 
> The difference is that I didn't call attach/detach with the lock held yet.
> 
> And we could actually drop locking the reservation object while manipulating
> the list of attachments since we no longer use that workaround.
> 
> Going to fix that up tomorrow as well,

You rely on the reservation lock for walking the list when calling
move_notify. So that lock is definitely needed there. If you'd put it in
there then lockdep would splat about locking inversions.

In general dmabuf->lock not being a ww_mutex kinda gets in the way and
just needless complicates the hierarchy. Atm its even outside of the
reservation lock, so anywhere where we expect callers to hold the
reservation lock already we can't take it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Daniel Vetter]

On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
> held.
> 
> On the importer side we add an optional invalidate callback. This callback is
> used by the exporter to inform the importers that their mappings should be
> destroyed as soon as possible.
> 
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
> 
> v2: don't try to invalidate mappings when the callback is NULL,
>     lock the reservation obj while using the attachments,
>     add helper to set the callback
> v3: move flag for invalidation support into the DMA-buf,
>     use new attach_info structure to set the callback
> v4: use importer_priv field instead of mangling exporter priv.
> v5: drop invalidation_supported flag
> v6: squash together with pin/unpin changes
> v7: pin/unpin takes an attachment now
> v8: nuke dma_buf_attachment_(map|unmap)_locked,
>     everything is now handled backward compatible
> v9: always cache when export/importer don't agree on dynamic handling
> v10: minimal style cleanup
> v11: drop automatically re-entry avoidance
> v12: rename callback to move_notify
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>

One thing I've forgotten, just stumbled over ttm_bo->moving. For pinned
buffer sharing that's not needed, and I think for dynamic buffer sharing
it's also not going to be the primary requirement. But I think there's two
reasons we should maybe look into moving that from ttm_bo to resv_obj:

- You sound like you want to use this a lot more, even internally in
  amdgpu. For that I do think the sepearate dma_fence just to make sure
  the buffer is accessible will be needed in resv_obj.

- Once we have ->moving I think there's some good chances to extract a bit
  of the eviction/pipeline bo move boilerplate from ttm, and maybe use it
  in other drivers. i915 could already make use of this in upstream, since
  we already pipeline get_pages and clflush of buffers. Ofc once we have
  vram support, even more useful.

And doing that slight semantic change is much easier once we only have a
few dynamic exporters/importers. And since it's a pure opt-in optimization
(you can always fall back to the exclusive fence) it should be easy to
roll out.

Thoughts about moving ttm_bo->moving to resv_obj? Ofc strictly only as a
follow up. Plus maybe with a clearer name :-)

Cheers, Daniel

> ---
>  drivers/dma-buf/dma-buf.c | 179 ++++++++++++++++++++++++++++++++++++--
>  include/linux/dma-buf.h   | 108 +++++++++++++++++++++--
>  2 files changed, 273 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 6c15deb5d4ad..216f76109f3f 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
>  		return ERR_PTR(-EINVAL);
>  	}
>  
> +	if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
> +		return ERR_PTR(-EINVAL);
> +
>  	if (!try_module_get(exp_info->owner))
>  		return ERR_PTR(-ENOENT);
>  
> @@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
>  EXPORT_SYMBOL_GPL(dma_buf_put);
>  
>  /**
> - * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
> + * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list; optionally,
>   * calls attach() of dma_buf_ops to allow device-specific attach functionality
> - * @dmabuf:	[in]	buffer to attach device to.
> - * @dev:	[in]	device to be attached.
> + * @dmabuf:		[in]	buffer to attach device to.
> + * @dev:		[in]	device to be attached.
> + * @importer_ops	[in]	importer operations for the attachment
> + * @importer_priv	[in]	importer private pointer for the attachment
>   *
>   * Returns struct dma_buf_attachment pointer for this attachment. Attachments
>   * must be cleaned up by calling dma_buf_detach().
> @@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
>   * accessible to @dev, and cannot be moved to a more suitable place. This is
>   * indicated with the error code -EBUSY.
>   */
> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> -					  struct device *dev)
> +struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> +		       const struct dma_buf_attach_ops *importer_ops,
> +		       void *importer_priv)
>  {
>  	struct dma_buf_attachment *attach;
>  	int ret;
> @@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>  
>  	attach->dev = dev;
>  	attach->dmabuf = dmabuf;
> +	attach->importer_ops = importer_ops;
> +	attach->importer_priv = importer_priv;
>  
>  	mutex_lock(&dmabuf->lock);
>  
> @@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>  		if (ret)
>  			goto err_attach;
>  	}
> +	reservation_object_lock(dmabuf->resv, NULL);
>  	list_add(&attach->node, &dmabuf->attachments);
> +	reservation_object_unlock(dmabuf->resv);
>  
>  	mutex_unlock(&dmabuf->lock);
>  
> +	/* When either the importer or the exporter can't handle dynamic
> +	 * mappings we cache the mapping here to avoid issues with the
> +	 * reservation object lock.
> +	 */
> +	if (dma_buf_attachment_is_dynamic(attach) !=
> +	    dma_buf_is_dynamic(dmabuf)) {
> +		struct sg_table *sgt;
> +
> +		if (dma_buf_is_dynamic(attach->dmabuf)) {
> +			reservation_object_lock(attach->dmabuf->resv, NULL);
> +			ret = dma_buf_pin(attach);
> +			if (ret)
> +				goto err_unlock;
> +		}
> +
> +		sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> +		if (!sgt)
> +			sgt = ERR_PTR(-ENOMEM);
> +		if (IS_ERR(sgt)) {
> +			ret = PTR_ERR(sgt);
> +			goto err_unpin;
> +		}
> +		if (dma_buf_is_dynamic(attach->dmabuf))
> +			reservation_object_unlock(attach->dmabuf->resv);
> +		attach->sgt = sgt;
> +		attach->dir = DMA_BIDIRECTIONAL;
> +	}
> +
>  	return attach;
>  
>  err_attach:
>  	kfree(attach);
>  	mutex_unlock(&dmabuf->lock);
>  	return ERR_PTR(ret);
> +
> +err_unpin:
> +	if (dma_buf_is_dynamic(attach->dmabuf))
> +		dma_buf_unpin(attach);
> +
> +err_unlock:
> +	if (dma_buf_is_dynamic(attach->dmabuf))
> +		reservation_object_unlock(attach->dmabuf->resv);
> +
> +	dma_buf_detach(dmabuf, attach);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
> +
> +/**
> + * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
> + * @dmabuf:	[in]	buffer to attach device to.
> + * @dev:	[in]	device to be attached.
> + *
> + * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a static
> + * mapping.
> + */
> +struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> +					  struct device *dev)
> +{
> +	return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_attach);
>  
> @@ -717,11 +782,22 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
>  	if (WARN_ON(!dmabuf || !attach))
>  		return;
>  
> -	if (attach->sgt)
> +	if (attach->sgt) {
> +		if (dma_buf_is_dynamic(attach->dmabuf))
> +			reservation_object_lock(attach->dmabuf->resv, NULL);
> +
>  		dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir);
>  
> +		if (dma_buf_is_dynamic(attach->dmabuf)) {
> +			dma_buf_unpin(attach);
> +			reservation_object_unlock(attach->dmabuf->resv);
> +		}
> +	}
> +
>  	mutex_lock(&dmabuf->lock);
> +	reservation_object_lock(dmabuf->resv, NULL);
>  	list_del(&attach->node);
> +	reservation_object_unlock(dmabuf->resv);
>  	if (dmabuf->ops->detach)
>  		dmabuf->ops->detach(dmabuf, attach);
>  
> @@ -730,6 +806,44 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_detach);
>  
> +/**
> + * dma_buf_pin - Lock down the DMA-buf
> + *
> + * @attach:	[in]	attachment which should be pinned
> + *
> + * Returns:
> + * 0 on success, negative error code on failure.
> + */
> +int dma_buf_pin(struct dma_buf_attachment *attach)
> +{
> +	struct dma_buf *dmabuf = attach->dmabuf;
> +	int ret = 0;
> +
> +	reservation_object_assert_held(dmabuf->resv);
> +
> +	if (dmabuf->ops->pin)
> +		ret = dmabuf->ops->pin(attach);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_pin);
> +
> +/**
> + * dma_buf_unpin - Remove lock from DMA-buf
> + *
> + * @attach:	[in]	attachment which should be unpinned
> + */
> +void dma_buf_unpin(struct dma_buf_attachment *attach)
> +{
> +	struct dma_buf *dmabuf = attach->dmabuf;
> +
> +	reservation_object_assert_held(dmabuf->resv);
> +
> +	if (dmabuf->ops->unpin)
> +		dmabuf->ops->unpin(attach);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_unpin);
> +
>  /**
>   * dma_buf_map_attachment - Returns the scatterlist table of the attachment;
>   * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
> @@ -749,6 +863,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>  					enum dma_data_direction direction)
>  {
>  	struct sg_table *sg_table;
> +	int r;
>  
>  	might_sleep();
>  
> @@ -767,10 +882,29 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>  		return attach->sgt;
>  	}
>  
> +	if (dma_buf_attachment_is_dynamic(attach)) {
> +		reservation_object_assert_held(attach->dmabuf->resv);
> +
> +	} else if (dma_buf_is_dynamic(attach->dmabuf)) {
> +		reservation_object_lock(attach->dmabuf->resv, NULL);
> +		r = dma_buf_pin(attach);
> +		if (r) {
> +			reservation_object_unlock(attach->dmabuf->resv);
> +			return ERR_PTR(r);
> +		}
> +	}
> +
>  	sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
>  	if (!sg_table)
>  		sg_table = ERR_PTR(-ENOMEM);
>  
> +	if (!dma_buf_attachment_is_dynamic(attach) &&
> +	    dma_buf_is_dynamic(attach->dmabuf)) {
> +		if (IS_ERR(sg_table))
> +			dma_buf_unpin(attach);
> +		reservation_object_unlock(attach->dmabuf->resv);
> +	}
> +
>  	if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
>  		attach->sgt = sg_table;
>  		attach->dir = direction;
> @@ -802,10 +936,41 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
>  	if (attach->sgt == sg_table)
>  		return;
>  
> +	if (dma_buf_attachment_is_dynamic(attach))
> +		reservation_object_assert_held(attach->dmabuf->resv);
> +	else if (dma_buf_is_dynamic(attach->dmabuf))
> +		reservation_object_lock(attach->dmabuf->resv, NULL);
> +
>  	attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
> +
> +	if (dma_buf_is_dynamic(attach->dmabuf) &&
> +	    !dma_buf_attachment_is_dynamic(attach)) {
> +		dma_buf_unpin(attach);
> +		reservation_object_unlock(attach->dmabuf->resv);
> +	}
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>  
> +/**
> + * dma_buf_move_notify - notify attachments that DMA-buf is moving
> + *
> + * @dmabuf:	[in]	buffer which is moving
> + *
> + * Informs all attachmenst that they need to destroy and recreated all their
> + * mappings.
> + */
> +void dma_buf_move_notify(struct dma_buf *dmabuf)
> +{
> +	struct dma_buf_attachment *attach;
> +
> +	reservation_object_assert_held(dmabuf->resv);
> +
> +	list_for_each_entry(attach, &dmabuf->attachments, node)
> +		if (attach->importer_ops && attach->importer_ops->move_notify)
> +			attach->importer_ops->move_notify(attach);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_move_notify);
> +
>  /**
>   * DOC: cpu access
>   *
> @@ -1225,10 +1390,12 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
>  		seq_puts(s, "\tAttached Devices:\n");
>  		attach_count = 0;
>  
> +		reservation_object_lock(buf_obj->resv, NULL);
>  		list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
>  			seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
>  			attach_count++;
>  		}
> +		reservation_object_unlock(buf_obj->resv);
>  
>  		seq_printf(s, "Total %d devices attached\n\n",
>  				attach_count);
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 01ad5b942a6f..ccad2fc1f640 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -92,14 +92,40 @@ struct dma_buf_ops {
>  	 */
>  	void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
>  
> +	/**
> +	 * @pin:
> +	 *
> +	 * This is called by dma_buf_pin and lets the exporter know that the
> +	 * DMA-buf can't be moved any more.
> +	 *
> +	 * This is called with the dmabuf->resv object locked.
> +	 *
> +	 * This callback is optional.
> +	 *
> +	 * Returns:
> +	 *
> +	 * 0 on success, negative error code on failure.
> +	 */
> +	int (*pin)(struct dma_buf_attachment *attach);
> +
> +	/**
> +	 * @unpin:
> +	 *
> +	 * This is called by dma_buf_unpin and lets the exporter know that the
> +	 * DMA-buf can be moved again.
> +	 *
> +	 * This is called with the dmabuf->resv object locked.
> +	 *
> +	 * This callback is optional.
> +	 */
> +	void (*unpin)(struct dma_buf_attachment *attach);
> +
>  	/**
>  	 * @map_dma_buf:
>  	 *
>  	 * This is called by dma_buf_map_attachment() and is used to map a
>  	 * shared &dma_buf into device address space, and it is mandatory. It
> -	 * can only be called if @attach has been called successfully. This
> -	 * essentially pins the DMA buffer into place, and it cannot be moved
> -	 * any more
> +	 * can only be called if @attach has been called successfully.
>  	 *
>  	 * This call may sleep, e.g. when the backing storage first needs to be
>  	 * allocated, or moved to a location suitable for all currently attached
> @@ -120,6 +146,9 @@ struct dma_buf_ops {
>  	 * any other kind of sharing that the exporter might wish to make
>  	 * available to buffer-users.
>  	 *
> +	 * This is always called with the dmabuf->resv object locked when
> +	 * the pin/unpin callbacks are implemented.
> +	 *
>  	 * Returns:
>  	 *
>  	 * A &sg_table scatter list of or the backing storage of the DMA buffer,
> @@ -137,9 +166,6 @@ struct dma_buf_ops {
>  	 *
>  	 * This is called by dma_buf_unmap_attachment() and should unmap and
>  	 * release the &sg_table allocated in @map_dma_buf, and it is mandatory.
> -	 * It should also unpin the backing storage if this is the last mapping
> -	 * of the DMA buffer, it the exporter supports backing storage
> -	 * migration.
>  	 */
>  	void (*unmap_dma_buf)(struct dma_buf_attachment *,
>  			      struct sg_table *,
> @@ -330,6 +356,34 @@ struct dma_buf {
>  	} cb_excl, cb_shared;
>  };
>  
> +/**
> + * struct dma_buf_attach_ops - importer operations for an attachment
> + * @move_notify: [optional] notification that the DMA-buf is moving
> + *
> + * Attachment operations implemented by the importer.
> + */
> +struct dma_buf_attach_ops {
> +	/**
> +	 * @move_notify
> +	 *
> +	 * If this callback is provided the framework can avoid pinning the
> +	 * backing store while mappings exists.
> +	 *
> +	 * This callback is called with the lock of the reservation object
> +	 * associated with the dma_buf held and the mapping function must be
> +	 * called with this lock held as well. This makes sure that no mapping
> +	 * is created concurrently with an ongoing move operation.
> +	 *
> +	 * Mappings stay valid and are not directly affected by this callback.
> +	 * But the DMA-buf can now be in a different physical location, so all
> +	 * mappings should be destroyed and re-created as soon as possible.
> +	 *
> +	 * New mappings can be created after this callback returns, and will
> +	 * point to the new location of the DMA-buf.
> +	 */
> +	void (*move_notify)(struct dma_buf_attachment *attach);
> +};
> +
>  /**
>   * struct dma_buf_attachment - holds device-buffer attachment data
>   * @dmabuf: buffer for this attachment.
> @@ -338,6 +392,8 @@ struct dma_buf {
>   * @sgt: cached mapping.
>   * @dir: direction of cached mapping.
>   * @priv: exporter specific attachment data.
> + * @importer_ops: importer operations for this attachment.
> + * @importer_priv: importer specific attachment data.
>   *
>   * This structure holds the attachment information between the dma_buf buffer
>   * and its user device(s). The list contains one attachment struct per device
> @@ -355,6 +411,9 @@ struct dma_buf_attachment {
>  	struct sg_table *sgt;
>  	enum dma_data_direction dir;
>  	void *priv;
> +
> +	const struct dma_buf_attach_ops *importer_ops;
> +	void *importer_priv;
>  };
>  
>  /**
> @@ -405,10 +464,42 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
>  	get_file(dmabuf->file);
>  }
>  
> +/**
> + * dma_buf_is_dynamic - check if a DMA-buf uses dynamic mappings.
> + * @dmabuf: the DMA-buf to check
> + *
> + * Returns true if a DMA-buf exporter wants to create dynamic sg table mappings
> + * for each attachment. False if only a single static sg table should be used.
> + */
> +static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
> +{
> +	return !!dmabuf->ops->pin;
> +}
> +
> +/**
> + * dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses dynamic
> + * mappinsg
> + * @attach: the DMA-buf attachment to check
> + *
> + * Returns true if a DMA-buf importer wants to use dynamic sg table mappings and
> + * calls the map/unmap functions with the reservation object locked.
> + */
> +static inline bool
> +dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
> +{
> +	return attach->importer_ops && attach->importer_ops->move_notify;
> +}
> +
>  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> -							struct device *dev);
> +					  struct device *dev);
> +struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> +		       const struct dma_buf_attach_ops *importer_ops,
> +		       void *importer_priv);
>  void dma_buf_detach(struct dma_buf *dmabuf,
> -				struct dma_buf_attachment *dmabuf_attach);
> +		    struct dma_buf_attachment *attach);
> +int dma_buf_pin(struct dma_buf_attachment *attach);
> +void dma_buf_unpin(struct dma_buf_attachment *attach);
>  
>  struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
>  
> @@ -420,6 +511,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
>  					enum dma_data_direction);
>  void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
>  				enum dma_data_direction);
> +void dma_buf_move_notify(struct dma_buf *dma_buf);
>  int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
>  			     enum dma_data_direction dir);
>  int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
> -- 
> 2.17.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Christian König]

Am 25.06.19 um 18:05 schrieb Daniel Vetter:
> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
>> On the exporter side we add optional explicit pinning callbacks. If those
>> callbacks are implemented the framework no longer caches sg tables and the
>> map/unmap callbacks are always called with the lock of the reservation object
>> held.
>>
>> On the importer side we add an optional invalidate callback. This callback is
>> used by the exporter to inform the importers that their mappings should be
>> destroyed as soon as possible.
>>
>> This allows the exporter to provide the mappings without the need to pin
>> the backing store.
>>
>> v2: don't try to invalidate mappings when the callback is NULL,
>>      lock the reservation obj while using the attachments,
>>      add helper to set the callback
>> v3: move flag for invalidation support into the DMA-buf,
>>      use new attach_info structure to set the callback
>> v4: use importer_priv field instead of mangling exporter priv.
>> v5: drop invalidation_supported flag
>> v6: squash together with pin/unpin changes
>> v7: pin/unpin takes an attachment now
>> v8: nuke dma_buf_attachment_(map|unmap)_locked,
>>      everything is now handled backward compatible
>> v9: always cache when export/importer don't agree on dynamic handling
>> v10: minimal style cleanup
>> v11: drop automatically re-entry avoidance
>> v12: rename callback to move_notify
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
> One thing I've forgotten, just stumbled over ttm_bo->moving. For pinned
> buffer sharing that's not needed, and I think for dynamic buffer sharing
> it's also not going to be the primary requirement. But I think there's two
> reasons we should maybe look into moving that from ttm_bo to resv_obj:

That is already part of the resv_obj. The difference is that radeon is 
overwriting the one in the resv_obj during CS while amdgpu isn't.

So for amdgpu we keep an extra copy in ttm_bo->moving to keep the page 
fault handler from unnecessary waiting for a fence in radeon.

>
> - You sound like you want to use this a lot more, even internally in
>    amdgpu. For that I do think the sepearate dma_fence just to make sure
>    the buffer is accessible will be needed in resv_obj.
>
> - Once we have ->moving I think there's some good chances to extract a bit
>    of the eviction/pipeline bo move boilerplate from ttm, and maybe use it
>    in other drivers. i915 could already make use of this in upstream, since
>    we already pipeline get_pages and clflush of buffers. Ofc once we have
>    vram support, even more useful.

I actually indeed wanted to add more stuff to the reservation object 
implementation, like finally cleaning up the distinction of readers/writers.

And cleaning up the fence removal hack we have in the KFD for freed up 
BOs. That would also allow for getting rid of this in the long term.

Christian.

>
> And doing that slight semantic change is much easier once we only have a
> few dynamic exporters/importers. And since it's a pure opt-in optimization
> (you can always fall back to the exclusive fence) it should be easy to
> roll out.
>
> Thoughts about moving ttm_bo->moving to resv_obj? Ofc strictly only as a
> follow up. Plus maybe with a clearer name :-)
>
> Cheers, Daniel
>

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Daniel Vetter]

On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
> > On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
> > > On the exporter side we add optional explicit pinning callbacks. If those
> > > callbacks are implemented the framework no longer caches sg tables and the
> > > map/unmap callbacks are always called with the lock of the reservation object
> > > held.
> > > 
> > > On the importer side we add an optional invalidate callback. This callback is
> > > used by the exporter to inform the importers that their mappings should be
> > > destroyed as soon as possible.
> > > 
> > > This allows the exporter to provide the mappings without the need to pin
> > > the backing store.
> > > 
> > > v2: don't try to invalidate mappings when the callback is NULL,
> > >      lock the reservation obj while using the attachments,
> > >      add helper to set the callback
> > > v3: move flag for invalidation support into the DMA-buf,
> > >      use new attach_info structure to set the callback
> > > v4: use importer_priv field instead of mangling exporter priv.
> > > v5: drop invalidation_supported flag
> > > v6: squash together with pin/unpin changes
> > > v7: pin/unpin takes an attachment now
> > > v8: nuke dma_buf_attachment_(map|unmap)_locked,
> > >      everything is now handled backward compatible
> > > v9: always cache when export/importer don't agree on dynamic handling
> > > v10: minimal style cleanup
> > > v11: drop automatically re-entry avoidance
> > > v12: rename callback to move_notify
> > > 
> > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > One thing I've forgotten, just stumbled over ttm_bo->moving. For pinned
> > buffer sharing that's not needed, and I think for dynamic buffer sharing
> > it's also not going to be the primary requirement. But I think there's two
> > reasons we should maybe look into moving that from ttm_bo to resv_obj:
> 
> That is already part of the resv_obj. The difference is that radeon is
> overwriting the one in the resv_obj during CS while amdgpu isn't.

I'm confused here: Atm ->moving isn't in resv_obj, there's only one
exclusive fence. And yes you need to set that every time you do a move
(because a move needs to be pretty exclusive access). But I'm not seeing a
separate not_quite_exclusive fence slot for moves.

> So for amdgpu we keep an extra copy in ttm_bo->moving to keep the page fault
> handler from unnecessary waiting for a fence in radeon.

Yeah that's the main one. The other is in CS (at least for i915) we could
run pipeline texture uploads in parallel with other rendering and stuff
like that (with multiple engines, which atm is also not there yet). I
think that could be somewhat useful for vk drivers.

Anyway, totally not understand what you wanted to tell me here in these
two lines.

> > - You sound like you want to use this a lot more, even internally in
> >    amdgpu. For that I do think the sepearate dma_fence just to make sure
> >    the buffer is accessible will be needed in resv_obj.
> > 
> > - Once we have ->moving I think there's some good chances to extract a bit
> >    of the eviction/pipeline bo move boilerplate from ttm, and maybe use it
> >    in other drivers. i915 could already make use of this in upstream, since
> >    we already pipeline get_pages and clflush of buffers. Ofc once we have
> >    vram support, even more useful.
> 
> I actually indeed wanted to add more stuff to the reservation object
> implementation, like finally cleaning up the distinction of readers/writers.

Hm, more details? Not ringing a bell ...

> And cleaning up the fence removal hack we have in the KFD for freed up BOs.
> That would also allow for getting rid of this in the long term.

Hm, what's that for?
-Daniel

> 
> Christian.
> 
> > 
> > And doing that slight semantic change is much easier once we only have a
> > few dynamic exporters/importers. And since it's a pure opt-in optimization
> > (you can always fall back to the exclusive fence) it should be easy to
> > roll out.
> > 
> > Thoughts about moving ttm_bo->moving to resv_obj? Ofc strictly only as a
> > follow up. Plus maybe with a clearer name :-)
> > 
> > Cheers, Daniel
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Koenig, Christian]

Am 26.06.19 um 10:17 schrieb Daniel Vetter:
> On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
>> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
>>> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
>>>> On the exporter side we add optional explicit pinning callbacks. If those
>>>> callbacks are implemented the framework no longer caches sg tables and the
>>>> map/unmap callbacks are always called with the lock of the reservation object
>>>> held.
>>>>
>>>> On the importer side we add an optional invalidate callback. This callback is
>>>> used by the exporter to inform the importers that their mappings should be
>>>> destroyed as soon as possible.
>>>>
>>>> This allows the exporter to provide the mappings without the need to pin
>>>> the backing store.
>>>>
>>>> v2: don't try to invalidate mappings when the callback is NULL,
>>>>       lock the reservation obj while using the attachments,
>>>>       add helper to set the callback
>>>> v3: move flag for invalidation support into the DMA-buf,
>>>>       use new attach_info structure to set the callback
>>>> v4: use importer_priv field instead of mangling exporter priv.
>>>> v5: drop invalidation_supported flag
>>>> v6: squash together with pin/unpin changes
>>>> v7: pin/unpin takes an attachment now
>>>> v8: nuke dma_buf_attachment_(map|unmap)_locked,
>>>>       everything is now handled backward compatible
>>>> v9: always cache when export/importer don't agree on dynamic handling
>>>> v10: minimal style cleanup
>>>> v11: drop automatically re-entry avoidance
>>>> v12: rename callback to move_notify
>>>>
>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>> One thing I've forgotten, just stumbled over ttm_bo->moving. For pinned
>>> buffer sharing that's not needed, and I think for dynamic buffer sharing
>>> it's also not going to be the primary requirement. But I think there's two
>>> reasons we should maybe look into moving that from ttm_bo to resv_obj:
>> That is already part of the resv_obj. The difference is that radeon is
>> overwriting the one in the resv_obj during CS while amdgpu isn't.
> I'm confused here: Atm ->moving isn't in resv_obj, there's only one
> exclusive fence. And yes you need to set that every time you do a move
> (because a move needs to be pretty exclusive access). But I'm not seeing a
> separate not_quite_exclusive fence slot for moves.

Yeah, but shouldn't that be sufficient? I mean why does somebody else 
than the exporter needs to know when a BO is moving?

>> So for amdgpu we keep an extra copy in ttm_bo->moving to keep the page fault
>> handler from unnecessary waiting for a fence in radeon.
> Yeah that's the main one. The other is in CS (at least for i915) we could
> run pipeline texture uploads in parallel with other rendering and stuff
> like that (with multiple engines, which atm is also not there yet). I
> think that could be somewhat useful for vk drivers.
>
> Anyway, totally not understand what you wanted to tell me here in these
> two lines.

Sorry it's 33C in my home office here and I mixed up radeon/amdgpu in 
the sentence above.

>>> - You sound like you want to use this a lot more, even internally in
>>>     amdgpu. For that I do think the sepearate dma_fence just to make sure
>>>     the buffer is accessible will be needed in resv_obj.
>>>
>>> - Once we have ->moving I think there's some good chances to extract a bit
>>>     of the eviction/pipeline bo move boilerplate from ttm, and maybe use it
>>>     in other drivers. i915 could already make use of this in upstream, since
>>>     we already pipeline get_pages and clflush of buffers. Ofc once we have
>>>     vram support, even more useful.
>> I actually indeed wanted to add more stuff to the reservation object
>> implementation, like finally cleaning up the distinction of readers/writers.
> Hm, more details? Not ringing a bell ...

I'm not yet sure about the details either, so please just wait until I 
solved that all up for me first.

>> And cleaning up the fence removal hack we have in the KFD for freed up BOs.
>> That would also allow for getting rid of this in the long term.
> Hm, what's that for?

When the KFD frees up memory it removes their eviction fence from the 
reservation object instead of setting it as signaled and adding a new 
one to all other used reservation objects.

Christian.

> -Daniel
>
>> Christian.
>>
>>> And doing that slight semantic change is much easier once we only have a
>>> few dynamic exporters/importers. And since it's a pure opt-in optimization
>>> (you can always fall back to the exclusive fence) it should be easy to
>>> roll out.
>>>
>>> Thoughts about moving ttm_bo->moving to resv_obj? Ofc strictly only as a
>>> follow up. Plus maybe with a clearer name :-)
>>>
>>> Cheers, Daniel
>>>

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Daniel Vetter]

On Wed, Jun 26, 2019 at 11:28 AM Koenig, Christian
<Christian.Koenig@amd.com> wrote:
>
> Am 26.06.19 um 10:17 schrieb Daniel Vetter:
> > On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
> >> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
> >>> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
> >>>> On the exporter side we add optional explicit pinning callbacks. If those
> >>>> callbacks are implemented the framework no longer caches sg tables and the
> >>>> map/unmap callbacks are always called with the lock of the reservation object
> >>>> held.
> >>>>
> >>>> On the importer side we add an optional invalidate callback. This callback is
> >>>> used by the exporter to inform the importers that their mappings should be
> >>>> destroyed as soon as possible.
> >>>>
> >>>> This allows the exporter to provide the mappings without the need to pin
> >>>> the backing store.
> >>>>
> >>>> v2: don't try to invalidate mappings when the callback is NULL,
> >>>>       lock the reservation obj while using the attachments,
> >>>>       add helper to set the callback
> >>>> v3: move flag for invalidation support into the DMA-buf,
> >>>>       use new attach_info structure to set the callback
> >>>> v4: use importer_priv field instead of mangling exporter priv.
> >>>> v5: drop invalidation_supported flag
> >>>> v6: squash together with pin/unpin changes
> >>>> v7: pin/unpin takes an attachment now
> >>>> v8: nuke dma_buf_attachment_(map|unmap)_locked,
> >>>>       everything is now handled backward compatible
> >>>> v9: always cache when export/importer don't agree on dynamic handling
> >>>> v10: minimal style cleanup
> >>>> v11: drop automatically re-entry avoidance
> >>>> v12: rename callback to move_notify
> >>>>
> >>>> Signed-off-by: Christian König <christian.koenig@amd.com>
> >>> One thing I've forgotten, just stumbled over ttm_bo->moving. For pinned
> >>> buffer sharing that's not needed, and I think for dynamic buffer sharing
> >>> it's also not going to be the primary requirement. But I think there's two
> >>> reasons we should maybe look into moving that from ttm_bo to resv_obj:
> >> That is already part of the resv_obj. The difference is that radeon is
> >> overwriting the one in the resv_obj during CS while amdgpu isn't.
> > I'm confused here: Atm ->moving isn't in resv_obj, there's only one
> > exclusive fence. And yes you need to set that every time you do a move
> > (because a move needs to be pretty exclusive access). But I'm not seeing a
> > separate not_quite_exclusive fence slot for moves.
>
> Yeah, but shouldn't that be sufficient? I mean why does somebody else
> than the exporter needs to know when a BO is moving?

I think for buffer sharing there's not much use for this, but it
sounded like you want to use ->move_notify also more internally. And
in that case, for vk, you want to be able to ignore the implicit
fences as much as possible. But you can't ignore the buffer moves ofc.
Hence tracking those separate could be useful.

amdgpu seems to be solving this internally by never attaching an
exclusive fence for implicit stuff, or something like that, except
when it's shared. But in general you need to assume a funky mix of
implicit and explicit sync'ed workloads, and for those tracking the
moves separately would be good.

> >> So for amdgpu we keep an extra copy in ttm_bo->moving to keep the page fault
> >> handler from unnecessary waiting for a fence in radeon.
> > Yeah that's the main one. The other is in CS (at least for i915) we could
> > run pipeline texture uploads in parallel with other rendering and stuff
> > like that (with multiple engines, which atm is also not there yet). I
> > think that could be somewhat useful for vk drivers.
> >
> > Anyway, totally not understand what you wanted to tell me here in these
> > two lines.
>
> Sorry it's 33C in my home office here and I mixed up radeon/amdgpu in
> the sentence above.

Same here, and yeah makes more sense.

> >>> - You sound like you want to use this a lot more, even internally in
> >>>     amdgpu. For that I do think the sepearate dma_fence just to make sure
> >>>     the buffer is accessible will be needed in resv_obj.
> >>>
> >>> - Once we have ->moving I think there's some good chances to extract a bit
> >>>     of the eviction/pipeline bo move boilerplate from ttm, and maybe use it
> >>>     in other drivers. i915 could already make use of this in upstream, since
> >>>     we already pipeline get_pages and clflush of buffers. Ofc once we have
> >>>     vram support, even more useful.
> >> I actually indeed wanted to add more stuff to the reservation object
> >> implementation, like finally cleaning up the distinction of readers/writers.
> > Hm, more details? Not ringing a bell ...
>
> I'm not yet sure about the details either, so please just wait until I
> solved that all up for me first.

Ah is this about amdgpu doing something else for implicit sync than
what's supposed to be done, and a bit a mismatch when you deal with
shared buffers?

> >> And cleaning up the fence removal hack we have in the KFD for freed up BOs.
> >> That would also allow for getting rid of this in the long term.
> > Hm, what's that for?
>
> When the KFD frees up memory it removes their eviction fence from the
> reservation object instead of setting it as signaled and adding a new
> one to all other used reservation objects.

Oh so just a fast-path for destryoing memory that's in-flight in some move?
-Daniel

>
> Christian.
>
> > -Daniel
> >
> >> Christian.
> >>
> >>> And doing that slight semantic change is much easier once we only have a
> >>> few dynamic exporters/importers. And since it's a pure opt-in optimization
> >>> (you can always fall back to the exclusive fence) it should be easy to
> >>> roll out.
> >>>
> >>> Thoughts about moving ttm_bo->moving to resv_obj? Ofc strictly only as a
> >>> follow up. Plus maybe with a clearer name :-)
> >>>
> >>> Cheers, Daniel
> >>>
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Christian König]

[SNIP]
>>>>> I'm confused here: Atm ->moving isn't in resv_obj, there's only one 
>>> exclusive fence. And yes you need to set that every time you do a move
>>> (because a move needs to be pretty exclusive access). But I'm not seeing a
>>> separate not_quite_exclusive fence slot for moves.
>> Yeah, but shouldn't that be sufficient? I mean why does somebody else
>> than the exporter needs to know when a BO is moving?
> I think for buffer sharing there's not much use for this, but it
> sounded like you want to use ->move_notify also more internally. And
> in that case, for vk, you want to be able to ignore the implicit
> fences as much as possible. But you can't ignore the buffer moves ofc.
> Hence tracking those separate could be useful.

Yeah, but for this case I can still rely on using ttm_bo->moving. So no 
need to actually change that.

> amdgpu seems to be solving this internally by never attaching an
> exclusive fence for implicit stuff, or something like that, except
> when it's shared. But in general you need to assume a funky mix of
> implicit and explicit sync'ed workloads, and for those tracking the
> moves separately would be good.

Actually we have an "owner" for each fence which is basically a "void*" 
pointer.

If we see that a command submission is coming from the same "owner" we 
just avoid synchronization at all.

For buffer moves the owner is simply NULL (or some other special value), 
and so we always sync to those.

[SNIP]
>>>>> - You sound like you want to use this a lot more, even internally in
>>>>>      amdgpu. For that I do think the sepearate dma_fence just to make sure
>>>>>      the buffer is accessible will be needed in resv_obj.
>>>>>
>>>>> - Once we have ->moving I think there's some good chances to extract a bit
>>>>>      of the eviction/pipeline bo move boilerplate from ttm, and maybe use it
>>>>>      in other drivers. i915 could already make use of this in upstream, since
>>>>>      we already pipeline get_pages and clflush of buffers. Ofc once we have
>>>>>      vram support, even more useful.
>>>> I actually indeed wanted to add more stuff to the reservation object
>>>> implementation, like finally cleaning up the distinction of readers/writers.
>>> Hm, more details? Not ringing a bell ...
>> I'm not yet sure about the details either, so please just wait until I
>> solved that all up for me first.
> Ah is this about amdgpu doing something else for implicit sync than
> what's supposed to be done, and a bit a mismatch when you deal with
> shared buffers?

Yes, exactly.

>>>> And cleaning up the fence removal hack we have in the KFD for freed up BOs.
>>>> That would also allow for getting rid of this in the long term.
>>> Hm, what's that for?
>> When the KFD frees up memory it removes their eviction fence from the
>> reservation object instead of setting it as signaled and adding a new
>> one to all other used reservation objects.
> Oh so just a fast-path for destryoing memory that's in-flight in some move?

Yes exactly that again.

Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v12

[Daniel Vetter]

On Wed, Jun 26, 2019 at 1:53 PM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> [SNIP]
> >>>>> I'm confused here: Atm ->moving isn't in resv_obj, there's only one
> >>> exclusive fence. And yes you need to set that every time you do a move
> >>> (because a move needs to be pretty exclusive access). But I'm not seeing a
> >>> separate not_quite_exclusive fence slot for moves.
> >> Yeah, but shouldn't that be sufficient? I mean why does somebody else
> >> than the exporter needs to know when a BO is moving?
> > I think for buffer sharing there's not much use for this, but it
> > sounded like you want to use ->move_notify also more internally. And
> > in that case, for vk, you want to be able to ignore the implicit
> > fences as much as possible. But you can't ignore the buffer moves ofc.
> > Hence tracking those separate could be useful.
>
> Yeah, but for this case I can still rely on using ttm_bo->moving. So no
> need to actually change that.

Hm maybe wasn't clear what I had in mind. Roughly this:

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 435d02f719a8..33bb4eabe2eb 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -214,8 +214,6 @@ struct ttm_buffer_object {
         * Members protected by a bo reservation.
         */

-       struct dma_fence *moving;
-
        struct drm_vma_offset_node vma_node;

        unsigned priority;
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 644a22dbe53b..1c8a8bd077a2 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -74,6 +74,8 @@ struct reservation_object {
        seqcount_t seq;

        struct dma_fence __rcu *fence_excl;
+
+       struct dma_fence _rcu *moving;
        struct reservation_object_list __rcu *fence;
 };

Plus all the sorted fiddling. With the idea that we'd extract a bunch
of these over. Essentially instead of ttm, amdgpu and i915 all having
different ways to track the bo move fences, standardize on one.

> > amdgpu seems to be solving this internally by never attaching an
> > exclusive fence for implicit stuff, or something like that, except
> > when it's shared. But in general you need to assume a funky mix of
> > implicit and explicit sync'ed workloads, and for those tracking the
> > moves separately would be good.
>
> Actually we have an "owner" for each fence which is basically a "void*"
> pointer.
>
> If we see that a command submission is coming from the same "owner" we
> just avoid synchronization at all.
>
> For buffer moves the owner is simply NULL (or some other special value),
> and so we always sync to those.

Hm I guess I'll wait for you to untangel that then.
-Daniel

> [SNIP]
> >>>>> - You sound like you want to use this a lot more, even internally in
> >>>>>      amdgpu. For that I do think the sepearate dma_fence just to make sure
> >>>>>      the buffer is accessible will be needed in resv_obj.
> >>>>>
> >>>>> - Once we have ->moving I think there's some good chances to extract a bit
> >>>>>      of the eviction/pipeline bo move boilerplate from ttm, and maybe use it
> >>>>>      in other drivers. i915 could already make use of this in upstream, since
> >>>>>      we already pipeline get_pages and clflush of buffers. Ofc once we have
> >>>>>      vram support, even more useful.
> >>>> I actually indeed wanted to add more stuff to the reservation object
> >>>> implementation, like finally cleaning up the distinction of readers/writers.
> >>> Hm, more details? Not ringing a bell ...
> >> I'm not yet sure about the details either, so please just wait until I
> >> solved that all up for me first.
> > Ah is this about amdgpu doing something else for implicit sync than
> > what's supposed to be done, and a bit a mismatch when you deal with
> > shared buffers?
>
> Yes, exactly.
>
> >>>> And cleaning up the fence removal hack we have in the KFD for freed up BOs.
> >>>> That would also allow for getting rid of this in the long term.
> >>> Hm, what's that for?
> >> When the KFD frees up memory it removes their eviction fence from the
> >> reservation object instead of setting it as signaled and adding a new
> >> one to all other used reservation objects.
> > Oh so just a fast-path for destryoing memory that's in-flight in some move?
>
> Yes exactly that again.
>
> Christian.



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

[Christian König]

Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index dc63707e426f..0da512341194 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -28,6 +28,7 @@
 #include <linux/file.h>
 #include <linux/pagemap.h>
 #include <linux/sync_file.h>
+#include <linux/dma-buf.h>
 
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_syncobj.h>
@@ -414,7 +415,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
 	/* Don't move this buffer if we have depleted our allowance
 	 * to move it. Don't move anything if the threshold is zero.
 	 */
-	if (p->bytes_moved < p->bytes_moved_threshold) {
+	if (p->bytes_moved < p->bytes_moved_threshold &&
+	    (!bo->gem_base.dma_buf ||
+	    list_empty(&bo->gem_base.dma_buf->attachments))) {
 		if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
 		    (bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
 			/* And don't move a CPU_ACCESS_REQUIRED BO to limited
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

[Christian König]

Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index dc63707e426f..0da512341194 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -28,6 +28,7 @@
 #include <linux/file.h>
 #include <linux/pagemap.h>
 #include <linux/sync_file.h>
+#include <linux/dma-buf.h>
 
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_syncobj.h>
@@ -414,7 +415,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
 	/* Don't move this buffer if we have depleted our allowance
 	 * to move it. Don't move anything if the threshold is zero.
 	 */
-	if (p->bytes_moved < p->bytes_moved_threshold) {
+	if (p->bytes_moved < p->bytes_moved_threshold &&
+	    (!bo->gem_base.dma_buf ||
+	    list_empty(&bo->gem_base.dma_buf->attachments))) {
 		if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
 		    (bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
 			/* And don't move a CPU_ACCESS_REQUIRED BO to limited
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

[Christian König]

Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index dc63707e426f..0da512341194 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -28,6 +28,7 @@
 #include <linux/file.h>
 #include <linux/pagemap.h>
 #include <linux/sync_file.h>
+#include <linux/dma-buf.h>
 
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_syncobj.h>
@@ -414,7 +415,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
 	/* Don't move this buffer if we have depleted our allowance
 	 * to move it. Don't move anything if the threshold is zero.
 	 */
-	if (p->bytes_moved < p->bytes_moved_threshold) {
+	if (p->bytes_moved < p->bytes_moved_threshold &&
+	    (!bo->gem_base.dma_buf ||
+	    list_empty(&bo->gem_base.dma_buf->attachments))) {
 		if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
 		    (bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
 			/* And don't move a CPU_ACCESS_REQUIRED BO to limited
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

[Christian König]

Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 3e2da24cd17a..a59780654335 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -26,6 +26,7 @@
  */
 #include <linux/pagemap.h>
 #include <linux/sync_file.h>
+#include <linux/dma-buf.h>
 #include <drm/drmP.h>
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_syncobj.h>
@@ -412,7 +413,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
 	/* Don't move this buffer if we have depleted our allowance
 	 * to move it. Don't move anything if the threshold is zero.
 	 */
-	if (p->bytes_moved < p->bytes_moved_threshold) {
+	if (p->bytes_moved < p->bytes_moved_threshold &&
+	    (!bo->gem_base.dma_buf ||
+	    list_empty(&bo->gem_base.dma_buf->attachments))) {
 		if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
 		    (bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
 			/* And don't move a CPU_ACCESS_REQUIRED BO to limited
-- 
2.17.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

[Christian König]

Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 3e2da24cd17a..a59780654335 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -26,6 +26,7 @@
  */
 #include <linux/pagemap.h>
 #include <linux/sync_file.h>
+#include <linux/dma-buf.h>
 #include <drm/drmP.h>
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_syncobj.h>
@@ -412,7 +413,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
 	/* Don't move this buffer if we have depleted our allowance
 	 * to move it. Don't move anything if the threshold is zero.
 	 */
-	if (p->bytes_moved < p->bytes_moved_threshold) {
+	if (p->bytes_moved < p->bytes_moved_threshold &&
+	    (!bo->gem_base.dma_buf ||
+	    list_empty(&bo->gem_base.dma_buf->attachments))) {
 		if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
 		    (bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
 			/* And don't move a CPU_ACCESS_REQUIRED BO to limited
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs

[Christian König]

Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d72cc583ebd1..9b2b62d22c01 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -26,6 +26,7 @@
  */
 #include <linux/pagemap.h>
 #include <linux/sync_file.h>
+#include <linux/dma-buf.h>
 #include <drm/drmP.h>
 #include <drm/amdgpu_drm.h>
 #include <drm/drm_syncobj.h>
@@ -412,7 +413,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
 	/* Don't move this buffer if we have depleted our allowance
 	 * to move it. Don't move anything if the threshold is zero.
 	 */
-	if (p->bytes_moved < p->bytes_moved_threshold) {
+	if (p->bytes_moved < p->bytes_moved_threshold &&
+	    (!bo->gem_base.dma_buf ||
+	    list_empty(&bo->gem_base.dma_buf->attachments))) {
 		if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
 		    (bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
 			/* And don't move a CPU_ACCESS_REQUIRED BO to limited
-- 
2.17.1

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