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

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

[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
v13: add might_lock in appropriate places

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

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6c15deb5d4ad..bd8611fa2cfa 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,31 @@ 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);
+		}
+	} else {
+		might_lock(&attach->dmabuf->resv->lock.base);
+	}
+
 	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 +938,43 @@ 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);
+	else
+		might_lock(&attach->dmabuf->resv->lock.base);
+
 	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 +1394,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

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

[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

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-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

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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-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

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

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

[Daniel Vetter]

On Wed, Jun 26, 2019 at 02:23:05PM +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
> v13: add might_lock in appropriate places

v14 with dmabuf->lock gone?

Also I looked at CI results and stuff, I guess you indeed didn't break the
world because Chris Wilson has faught back struct_mutex far enough by now.

Other issue is that since 2 weeks or so our CI started filtering all
lockdep splats, so you need to dig into results yourself.

btw on that, I think in the end the reservation_obj locking will at best
be consistent between amdgpu and i915: I just remembered that all other
ttm drivers have the mmap_sem vs resv_obj locking the wrong way round, and
the trylock in ttm_bo_fault. So that part alone is hopeless, but I guess
since radeon.ko is abandonware no one will ever fix that.

So I think in the end it boils down to whether that's good enough to land
it, or not.
-Daniel

> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
>  drivers/dma-buf/dma-buf.c | 183 ++++++++++++++++++++++++++++++++++++--
>  include/linux/dma-buf.h   | 108 ++++++++++++++++++++--
>  2 files changed, 277 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 6c15deb5d4ad..bd8611fa2cfa 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,31 @@ 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);
> +		}
> +	} else {
> +		might_lock(&attach->dmabuf->resv->lock.base);
> +	}
> +
>  	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 +938,43 @@ 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);
> +	else
> +		might_lock(&attach->dmabuf->resv->lock.base);
> +
>  	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 +1394,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
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Patchwork]

== Series Details ==

Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13
URL   : https://patchwork.freedesktop.org/series/62777/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6d09a7de3969 dma-buf: add dynamic DMA-buf handling v13
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#11: 
map/unmap callbacks are always called with the lock of the reservation object

-:505: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 2 warnings, 0 checks, 439 lines checked
8f8445fa6219 drm/ttm: remove the backing store if no placement is given
-:36: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 1 warnings, 0 checks, 18 lines checked
4624e4f46a05 drm/ttm: use the parent resv for ghost objects v2
-:88: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 1 warnings, 0 checks, 62 lines checked
b0d7a97cb362 drm/amdgpu: use allowed_domains for exported DMA-bufs
-:36: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 1 warnings, 0 checks, 17 lines checked
13b9bef056c0 drm/amdgpu: add independent DMA-buf export v6
-:338: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 1 warnings, 0 checks, 293 lines checked
fbf9925e3e02 drm/amdgpu: add independent DMA-buf import v7
-:280: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König <ckoenig.leichtzumerken@gmail.com>'

total: 0 errors, 1 warnings, 0 checks, 222 lines checked

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

✗ Fi.CI.SPARSE: warning for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Patchwork]

== Series Details ==

Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13
URL   : https://patchwork.freedesktop.org/series/62777/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: dma-buf: add dynamic DMA-buf handling v13
Okay!

Commit: drm/ttm: remove the backing store if no placement is given
Okay!

Commit: drm/ttm: use the parent resv for ghost objects v2
Okay!

Commit: drm/amdgpu: use allowed_domains for exported DMA-bufs
Okay!

Commit: drm/amdgpu: add independent DMA-buf export v6
-drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:89:5: warning: symbol 'amdgpu_gem_prime_mmap' was not declared. Should it be static?
-drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:333:27: warning: symbol 'amdgpu_gem_prime_res_obj' was not declared. Should it be static?
-O:drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:324:26: warning: symbol 'amdgpu_dmabuf_ops' was not declared. Should it be static?
-drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:406:16: warning: symbol 'amdgpu_gem_prime_export' was not declared. Should it be static?
-drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:438:23: warning: symbol 'amdgpu_gem_prime_import_sg_table' was not declared. Should it be static?
-drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:487:23: warning: symbol 'amdgpu_gem_prime_import' was not declared. Should it be static?
-O:drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:49:17: warning: symbol 'amdgpu_gem_prime_get_sg_table' was not declared. Should it be static?
-drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:51:6: warning: symbol 'amdgpu_gem_prime_vmap' was not declared. Should it be static?
-drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:71:6: warning: symbol 'amdgpu_gem_prime_vunmap' was not declared. Should it be static?

Commit: drm/amdgpu: add independent DMA-buf import v7
Okay!

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

✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Patchwork]

== Series Details ==

Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13
URL   : https://patchwork.freedesktop.org/series/62777/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6358 -> Patchwork_13438
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_13438 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_13438, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_13438:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live_contexts:
    - fi-kbl-7567u:       [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7567u/igt@i915_selftest@live_contexts.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7567u/igt@i915_selftest@live_contexts.html

  * igt@i915_selftest@live_hugepages:
    - fi-skl-gvtdvm:      [PASS][3] -> [INCOMPLETE][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html

  
Known issues
------------

  Here are the changes found in Patchwork_13438 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_basic@create-close:
    - fi-icl-u3:          [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_basic@create-close.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_basic@create-close.html

  * igt@gem_ctx_switch@basic-default:
    - fi-icl-guc:         [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#108569])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-guc/igt@gem_ctx_switch@basic-default.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-guc/igt@gem_ctx_switch@basic-default.html

  * igt@gem_exec_create@basic:
    - fi-icl-u2:          [PASS][9] -> [INCOMPLETE][10] ([fdo#107713])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u2/igt@gem_exec_create@basic.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u2/igt@gem_exec_create@basic.html

  * igt@gem_exec_fence@basic-busy-default:
    - fi-blb-e6850:       [PASS][11] -> [DMESG-WARN][12] ([fdo#110913 ])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-blb-e6850/igt@gem_exec_fence@basic-busy-default.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-blb-e6850/igt@gem_exec_fence@basic-busy-default.html
    - fi-cfl-guc:         [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 ])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-guc/igt@gem_exec_fence@basic-busy-default.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-guc/igt@gem_exec_fence@basic-busy-default.html
    - fi-skl-guc:         [PASS][15] -> [DMESG-WARN][16] ([fdo#110913 ])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-guc/igt@gem_exec_fence@basic-busy-default.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-guc/igt@gem_exec_fence@basic-busy-default.html
    - fi-apl-guc:         [PASS][17] -> [DMESG-WARN][18] ([fdo#110913 ])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-apl-guc/igt@gem_exec_fence@basic-busy-default.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-apl-guc/igt@gem_exec_fence@basic-busy-default.html
    - fi-hsw-4770r:       [PASS][19] -> [DMESG-WARN][20] ([fdo#110913 ])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-4770r/igt@gem_exec_fence@basic-busy-default.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-4770r/igt@gem_exec_fence@basic-busy-default.html
    - fi-glk-dsi:         [PASS][21] -> [DMESG-WARN][22] ([fdo#110913 ])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-glk-dsi/igt@gem_exec_fence@basic-busy-default.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-glk-dsi/igt@gem_exec_fence@basic-busy-default.html
    - fi-pnv-d510:        [PASS][23] -> [DMESG-WARN][24] ([fdo#110913 ])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-pnv-d510/igt@gem_exec_fence@basic-busy-default.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-pnv-d510/igt@gem_exec_fence@basic-busy-default.html
    - fi-skl-6600u:       [PASS][25] -> [DMESG-WARN][26] ([fdo#110913 ])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6600u/igt@gem_exec_fence@basic-busy-default.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6600u/igt@gem_exec_fence@basic-busy-default.html
    - fi-hsw-peppy:       [PASS][27] -> [DMESG-WARN][28] ([fdo#110913 ])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-peppy/igt@gem_exec_fence@basic-busy-default.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-peppy/igt@gem_exec_fence@basic-busy-default.html
    - fi-kbl-x1275:       [PASS][29] -> [DMESG-WARN][30] ([fdo#110913 ])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-x1275/igt@gem_exec_fence@basic-busy-default.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-x1275/igt@gem_exec_fence@basic-busy-default.html
    - fi-cfl-8700k:       [PASS][31] -> [DMESG-WARN][32] ([fdo#110913 ])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-8700k/igt@gem_exec_fence@basic-busy-default.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-8700k/igt@gem_exec_fence@basic-busy-default.html
    - fi-icl-dsi:         [PASS][33] -> [DMESG-WARN][34] ([fdo#110913 ])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-dsi/igt@gem_exec_fence@basic-busy-default.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-dsi/igt@gem_exec_fence@basic-busy-default.html
    - fi-bdw-5557u:       [PASS][35] -> [DMESG-WARN][36] ([fdo#110913 ])
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bdw-5557u/igt@gem_exec_fence@basic-busy-default.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bdw-5557u/igt@gem_exec_fence@basic-busy-default.html
    - fi-kbl-7500u:       [PASS][37] -> [DMESG-WARN][38] ([fdo#110913 ])
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7500u/igt@gem_exec_fence@basic-busy-default.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7500u/igt@gem_exec_fence@basic-busy-default.html
    - fi-kbl-8809g:       [PASS][39] -> [DMESG-WARN][40] ([fdo#110913 ])
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-8809g/igt@gem_exec_fence@basic-busy-default.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-8809g/igt@gem_exec_fence@basic-busy-default.html
    - fi-bxt-dsi:         [PASS][41] -> [DMESG-WARN][42] ([fdo#109385] / [fdo#110913 ])
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bxt-dsi/igt@gem_exec_fence@basic-busy-default.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bxt-dsi/igt@gem_exec_fence@basic-busy-default.html
    - fi-whl-u:           [PASS][43] -> [DMESG-WARN][44] ([fdo#110913 ])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-whl-u/igt@gem_exec_fence@basic-busy-default.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-whl-u/igt@gem_exec_fence@basic-busy-default.html
    - fi-skl-gvtdvm:      [PASS][45] -> [DMESG-WARN][46] ([fdo#110913 ])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
    - fi-cml-u:           [PASS][47] -> [DMESG-WARN][48] ([fdo#110913 ])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
    - fi-bsw-n3050:       [PASS][49] -> [DMESG-WARN][50] ([fdo#109385] / [fdo#110913 ])
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bsw-n3050/igt@gem_exec_fence@basic-busy-default.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bsw-n3050/igt@gem_exec_fence@basic-busy-default.html
    - fi-ilk-650:         [PASS][51] -> [DMESG-WARN][52] ([fdo#110913 ])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-ilk-650/igt@gem_exec_fence@basic-busy-default.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-ilk-650/igt@gem_exec_fence@basic-busy-default.html
    - fi-hsw-4770:        [PASS][53] -> [DMESG-WARN][54] ([fdo#110913 ])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-4770/igt@gem_exec_fence@basic-busy-default.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-4770/igt@gem_exec_fence@basic-busy-default.html
    - fi-bdw-gvtdvm:      [PASS][55] -> [DMESG-WARN][56] ([fdo#110913 ])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bdw-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bdw-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
    - fi-skl-iommu:       [PASS][57] -> [DMESG-WARN][58] ([fdo#110913 ])
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-iommu/igt@gem_exec_fence@basic-busy-default.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-iommu/igt@gem_exec_fence@basic-busy-default.html
    - fi-kbl-7567u:       [PASS][59] -> [DMESG-WARN][60] ([fdo#110913 ])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7567u/igt@gem_exec_fence@basic-busy-default.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7567u/igt@gem_exec_fence@basic-busy-default.html
    - fi-ivb-3770:        [PASS][61] -> [DMESG-WARN][62] ([fdo#110913 ])
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-ivb-3770/igt@gem_exec_fence@basic-busy-default.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-ivb-3770/igt@gem_exec_fence@basic-busy-default.html
    - fi-snb-2520m:       [PASS][63] -> [DMESG-WARN][64] ([fdo#110913 ])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-snb-2520m/igt@gem_exec_fence@basic-busy-default.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-snb-2520m/igt@gem_exec_fence@basic-busy-default.html
    - fi-kbl-guc:         [PASS][65] -> [DMESG-WARN][66] ([fdo#110913 ])
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-guc/igt@gem_exec_fence@basic-busy-default.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-guc/igt@gem_exec_fence@basic-busy-default.html
    - fi-bsw-kefka:       [PASS][67] -> [DMESG-WARN][68] ([fdo#109385] / [fdo#110913 ])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bsw-kefka/igt@gem_exec_fence@basic-busy-default.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bsw-kefka/igt@gem_exec_fence@basic-busy-default.html
    - fi-kbl-r:           [PASS][69] -> [DMESG-WARN][70] ([fdo#110913 ])
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-r/igt@gem_exec_fence@basic-busy-default.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-r/igt@gem_exec_fence@basic-busy-default.html
    - fi-skl-6770hq:      [PASS][71] -> [DMESG-WARN][72] ([fdo#110913 ])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6770hq/igt@gem_exec_fence@basic-busy-default.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6770hq/igt@gem_exec_fence@basic-busy-default.html
    - fi-byt-n2820:       [PASS][73] -> [DMESG-WARN][74] ([fdo#110913 ])
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-byt-n2820/igt@gem_exec_fence@basic-busy-default.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-byt-n2820/igt@gem_exec_fence@basic-busy-default.html
    - fi-cfl-8109u:       [PASS][75] -> [DMESG-WARN][76] ([fdo#110913 ])
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-8109u/igt@gem_exec_fence@basic-busy-default.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-8109u/igt@gem_exec_fence@basic-busy-default.html
    - fi-icl-u3:          [PASS][77] -> [DMESG-WARN][78] ([fdo#110913 ])
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_exec_fence@basic-busy-default.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_exec_fence@basic-busy-default.html
    - fi-byt-j1900:       [PASS][79] -> [DMESG-WARN][80] ([fdo#110913 ])
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-byt-j1900/igt@gem_exec_fence@basic-busy-default.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-byt-j1900/igt@gem_exec_fence@basic-busy-default.html
    - fi-skl-6260u:       [PASS][81] -> [DMESG-WARN][82] ([fdo#110913 ])
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6260u/igt@gem_exec_fence@basic-busy-default.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6260u/igt@gem_exec_fence@basic-busy-default.html
    - fi-bxt-j4205:       [PASS][83] -> [DMESG-WARN][84] ([fdo#109385] / [fdo#110913 ])
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bxt-j4205/igt@gem_exec_fence@basic-busy-default.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bxt-j4205/igt@gem_exec_fence@basic-busy-default.html
    - fi-snb-2600:        [PASS][85] -> [DMESG-WARN][86] ([fdo#110913 ])
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-snb-2600/igt@gem_exec_fence@basic-busy-default.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-snb-2600/igt@gem_exec_fence@basic-busy-default.html
    - fi-elk-e7500:       [PASS][87] -> [DMESG-WARN][88] ([fdo#110913 ])
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-elk-e7500/igt@gem_exec_fence@basic-busy-default.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-elk-e7500/igt@gem_exec_fence@basic-busy-default.html
    - fi-skl-6700k2:      [PASS][89] -> [DMESG-WARN][90] ([fdo#110913 ])
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6700k2/igt@gem_exec_fence@basic-busy-default.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6700k2/igt@gem_exec_fence@basic-busy-default.html

  
#### Possible fixes ####

  * igt@gem_exec_fence@basic-wait-default:
    - fi-icl-u3:          [DMESG-WARN][91] ([fdo#107724]) -> [PASS][92] +2 similar issues
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_exec_fence@basic-wait-default.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_exec_fence@basic-wait-default.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109385]: https://bugs.freedesktop.org/show_bug.cgi?id=109385
  [fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913 


Participating hosts (54 -> 46)
------------------------------

  Additional (1): fi-cml-u2 
  Missing    (9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_6358 -> Patchwork_13438

  CI_DRM_6358: 3454454b146cd9f684feb07ab9dff61dc875a022 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5068: 15ad664534413628f06c0f172aac11598bfdb895 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13438: fbf9925e3e0220296c42260729dff5cc9d5d4c84 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fbf9925e3e02 drm/amdgpu: add independent DMA-buf import v7
13b9bef056c0 drm/amdgpu: add independent DMA-buf export v6
b0d7a97cb362 drm/amdgpu: use allowed_domains for exported DMA-bufs
4624e4f46a05 drm/ttm: use the parent resv for ghost objects v2
8f8445fa6219 drm/ttm: remove the backing store if no placement is given
6d09a7de3969 dma-buf: add dynamic DMA-buf handling v13

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Christian König]

Hi Daniel,

those fails look like something random to me and not related to my patch 
set. Correct?

Christian.

Am 26.06.19 um 15:32 schrieb Patchwork:
> == Series Details ==
>
> Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13
> URL   : https://patchwork.freedesktop.org/series/62777/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6358 -> Patchwork_13438
> ====================================================
>
> Summary
> -------
>
>    **FAILURE**
>
>    Serious unknown changes coming with Patchwork_13438 absolutely need to be
>    verified manually.
>    
>    If you think the reported changes have nothing to do with the changes
>    introduced in Patchwork_13438, please notify your bug team to allow them
>    to document this new failure mode, which will reduce false positives in CI.
>
>    External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/
>
> Possible new issues
> -------------------
>
>    Here are the unknown changes that may have been introduced in Patchwork_13438:
>
> ### IGT changes ###
>
> #### Possible regressions ####
>
>    * igt@i915_selftest@live_contexts:
>      - fi-kbl-7567u:       [PASS][1] -> [INCOMPLETE][2]
>     [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7567u/igt@i915_selftest@live_contexts.html
>     [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7567u/igt@i915_selftest@live_contexts.html
>
>    * igt@i915_selftest@live_hugepages:
>      - fi-skl-gvtdvm:      [PASS][3] -> [INCOMPLETE][4]
>     [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html
>     [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html
>
>    
> Known issues
> ------------
>
>    Here are the changes found in Patchwork_13438 that come from known issues:
>
> ### IGT changes ###
>
> #### Issues hit ####
>
>    * igt@gem_basic@create-close:
>      - fi-icl-u3:          [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
>     [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_basic@create-close.html
>     [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_basic@create-close.html
>
>    * igt@gem_ctx_switch@basic-default:
>      - fi-icl-guc:         [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#108569])
>     [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-guc/igt@gem_ctx_switch@basic-default.html
>     [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-guc/igt@gem_ctx_switch@basic-default.html
>
>    * igt@gem_exec_create@basic:
>      - fi-icl-u2:          [PASS][9] -> [INCOMPLETE][10] ([fdo#107713])
>     [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u2/igt@gem_exec_create@basic.html
>     [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u2/igt@gem_exec_create@basic.html
>
>    * igt@gem_exec_fence@basic-busy-default:
>      - fi-blb-e6850:       [PASS][11] -> [DMESG-WARN][12] ([fdo#110913 ])
>     [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-blb-e6850/igt@gem_exec_fence@basic-busy-default.html
>     [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-blb-e6850/igt@gem_exec_fence@basic-busy-default.html
>      - fi-cfl-guc:         [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 ])
>     [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-guc/igt@gem_exec_fence@basic-busy-default.html
>     [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-guc/igt@gem_exec_fence@basic-busy-default.html
>      - fi-skl-guc:         [PASS][15] -> [DMESG-WARN][16] ([fdo#110913 ])
>     [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-guc/igt@gem_exec_fence@basic-busy-default.html
>     [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-guc/igt@gem_exec_fence@basic-busy-default.html
>      - fi-apl-guc:         [PASS][17] -> [DMESG-WARN][18] ([fdo#110913 ])
>     [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-apl-guc/igt@gem_exec_fence@basic-busy-default.html
>     [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-apl-guc/igt@gem_exec_fence@basic-busy-default.html
>      - fi-hsw-4770r:       [PASS][19] -> [DMESG-WARN][20] ([fdo#110913 ])
>     [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-4770r/igt@gem_exec_fence@basic-busy-default.html
>     [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-4770r/igt@gem_exec_fence@basic-busy-default.html
>      - fi-glk-dsi:         [PASS][21] -> [DMESG-WARN][22] ([fdo#110913 ])
>     [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-glk-dsi/igt@gem_exec_fence@basic-busy-default.html
>     [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-glk-dsi/igt@gem_exec_fence@basic-busy-default.html
>      - fi-pnv-d510:        [PASS][23] -> [DMESG-WARN][24] ([fdo#110913 ])
>     [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-pnv-d510/igt@gem_exec_fence@basic-busy-default.html
>     [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-pnv-d510/igt@gem_exec_fence@basic-busy-default.html
>      - fi-skl-6600u:       [PASS][25] -> [DMESG-WARN][26] ([fdo#110913 ])
>     [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6600u/igt@gem_exec_fence@basic-busy-default.html
>     [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6600u/igt@gem_exec_fence@basic-busy-default.html
>      - fi-hsw-peppy:       [PASS][27] -> [DMESG-WARN][28] ([fdo#110913 ])
>     [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-peppy/igt@gem_exec_fence@basic-busy-default.html
>     [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-peppy/igt@gem_exec_fence@basic-busy-default.html
>      - fi-kbl-x1275:       [PASS][29] -> [DMESG-WARN][30] ([fdo#110913 ])
>     [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-x1275/igt@gem_exec_fence@basic-busy-default.html
>     [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-x1275/igt@gem_exec_fence@basic-busy-default.html
>      - fi-cfl-8700k:       [PASS][31] -> [DMESG-WARN][32] ([fdo#110913 ])
>     [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-8700k/igt@gem_exec_fence@basic-busy-default.html
>     [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-8700k/igt@gem_exec_fence@basic-busy-default.html
>      - fi-icl-dsi:         [PASS][33] -> [DMESG-WARN][34] ([fdo#110913 ])
>     [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-dsi/igt@gem_exec_fence@basic-busy-default.html
>     [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-dsi/igt@gem_exec_fence@basic-busy-default.html
>      - fi-bdw-5557u:       [PASS][35] -> [DMESG-WARN][36] ([fdo#110913 ])
>     [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bdw-5557u/igt@gem_exec_fence@basic-busy-default.html
>     [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bdw-5557u/igt@gem_exec_fence@basic-busy-default.html
>      - fi-kbl-7500u:       [PASS][37] -> [DMESG-WARN][38] ([fdo#110913 ])
>     [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7500u/igt@gem_exec_fence@basic-busy-default.html
>     [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7500u/igt@gem_exec_fence@basic-busy-default.html
>      - fi-kbl-8809g:       [PASS][39] -> [DMESG-WARN][40] ([fdo#110913 ])
>     [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-8809g/igt@gem_exec_fence@basic-busy-default.html
>     [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-8809g/igt@gem_exec_fence@basic-busy-default.html
>      - fi-bxt-dsi:         [PASS][41] -> [DMESG-WARN][42] ([fdo#109385] / [fdo#110913 ])
>     [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bxt-dsi/igt@gem_exec_fence@basic-busy-default.html
>     [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bxt-dsi/igt@gem_exec_fence@basic-busy-default.html
>      - fi-whl-u:           [PASS][43] -> [DMESG-WARN][44] ([fdo#110913 ])
>     [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-whl-u/igt@gem_exec_fence@basic-busy-default.html
>     [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-whl-u/igt@gem_exec_fence@basic-busy-default.html
>      - fi-skl-gvtdvm:      [PASS][45] -> [DMESG-WARN][46] ([fdo#110913 ])
>     [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
>     [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
>      - fi-cml-u:           [PASS][47] -> [DMESG-WARN][48] ([fdo#110913 ])
>     [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
>     [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
>      - fi-bsw-n3050:       [PASS][49] -> [DMESG-WARN][50] ([fdo#109385] / [fdo#110913 ])
>     [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bsw-n3050/igt@gem_exec_fence@basic-busy-default.html
>     [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bsw-n3050/igt@gem_exec_fence@basic-busy-default.html
>      - fi-ilk-650:         [PASS][51] -> [DMESG-WARN][52] ([fdo#110913 ])
>     [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-ilk-650/igt@gem_exec_fence@basic-busy-default.html
>     [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-ilk-650/igt@gem_exec_fence@basic-busy-default.html
>      - fi-hsw-4770:        [PASS][53] -> [DMESG-WARN][54] ([fdo#110913 ])
>     [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-4770/igt@gem_exec_fence@basic-busy-default.html
>     [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-4770/igt@gem_exec_fence@basic-busy-default.html
>      - fi-bdw-gvtdvm:      [PASS][55] -> [DMESG-WARN][56] ([fdo#110913 ])
>     [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bdw-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
>     [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bdw-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
>      - fi-skl-iommu:       [PASS][57] -> [DMESG-WARN][58] ([fdo#110913 ])
>     [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-iommu/igt@gem_exec_fence@basic-busy-default.html
>     [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-iommu/igt@gem_exec_fence@basic-busy-default.html
>      - fi-kbl-7567u:       [PASS][59] -> [DMESG-WARN][60] ([fdo#110913 ])
>     [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7567u/igt@gem_exec_fence@basic-busy-default.html
>     [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7567u/igt@gem_exec_fence@basic-busy-default.html
>      - fi-ivb-3770:        [PASS][61] -> [DMESG-WARN][62] ([fdo#110913 ])
>     [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-ivb-3770/igt@gem_exec_fence@basic-busy-default.html
>     [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-ivb-3770/igt@gem_exec_fence@basic-busy-default.html
>      - fi-snb-2520m:       [PASS][63] -> [DMESG-WARN][64] ([fdo#110913 ])
>     [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-snb-2520m/igt@gem_exec_fence@basic-busy-default.html
>     [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-snb-2520m/igt@gem_exec_fence@basic-busy-default.html
>      - fi-kbl-guc:         [PASS][65] -> [DMESG-WARN][66] ([fdo#110913 ])
>     [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-guc/igt@gem_exec_fence@basic-busy-default.html
>     [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-guc/igt@gem_exec_fence@basic-busy-default.html
>      - fi-bsw-kefka:       [PASS][67] -> [DMESG-WARN][68] ([fdo#109385] / [fdo#110913 ])
>     [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bsw-kefka/igt@gem_exec_fence@basic-busy-default.html
>     [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bsw-kefka/igt@gem_exec_fence@basic-busy-default.html
>      - fi-kbl-r:           [PASS][69] -> [DMESG-WARN][70] ([fdo#110913 ])
>     [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-r/igt@gem_exec_fence@basic-busy-default.html
>     [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-r/igt@gem_exec_fence@basic-busy-default.html
>      - fi-skl-6770hq:      [PASS][71] -> [DMESG-WARN][72] ([fdo#110913 ])
>     [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6770hq/igt@gem_exec_fence@basic-busy-default.html
>     [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6770hq/igt@gem_exec_fence@basic-busy-default.html
>      - fi-byt-n2820:       [PASS][73] -> [DMESG-WARN][74] ([fdo#110913 ])
>     [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-byt-n2820/igt@gem_exec_fence@basic-busy-default.html
>     [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-byt-n2820/igt@gem_exec_fence@basic-busy-default.html
>      - fi-cfl-8109u:       [PASS][75] -> [DMESG-WARN][76] ([fdo#110913 ])
>     [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-8109u/igt@gem_exec_fence@basic-busy-default.html
>     [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-8109u/igt@gem_exec_fence@basic-busy-default.html
>      - fi-icl-u3:          [PASS][77] -> [DMESG-WARN][78] ([fdo#110913 ])
>     [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_exec_fence@basic-busy-default.html
>     [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_exec_fence@basic-busy-default.html
>      - fi-byt-j1900:       [PASS][79] -> [DMESG-WARN][80] ([fdo#110913 ])
>     [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-byt-j1900/igt@gem_exec_fence@basic-busy-default.html
>     [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-byt-j1900/igt@gem_exec_fence@basic-busy-default.html
>      - fi-skl-6260u:       [PASS][81] -> [DMESG-WARN][82] ([fdo#110913 ])
>     [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6260u/igt@gem_exec_fence@basic-busy-default.html
>     [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6260u/igt@gem_exec_fence@basic-busy-default.html
>      - fi-bxt-j4205:       [PASS][83] -> [DMESG-WARN][84] ([fdo#109385] / [fdo#110913 ])
>     [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bxt-j4205/igt@gem_exec_fence@basic-busy-default.html
>     [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bxt-j4205/igt@gem_exec_fence@basic-busy-default.html
>      - fi-snb-2600:        [PASS][85] -> [DMESG-WARN][86] ([fdo#110913 ])
>     [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-snb-2600/igt@gem_exec_fence@basic-busy-default.html
>     [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-snb-2600/igt@gem_exec_fence@basic-busy-default.html
>      - fi-elk-e7500:       [PASS][87] -> [DMESG-WARN][88] ([fdo#110913 ])
>     [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-elk-e7500/igt@gem_exec_fence@basic-busy-default.html
>     [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-elk-e7500/igt@gem_exec_fence@basic-busy-default.html
>      - fi-skl-6700k2:      [PASS][89] -> [DMESG-WARN][90] ([fdo#110913 ])
>     [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6700k2/igt@gem_exec_fence@basic-busy-default.html
>     [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6700k2/igt@gem_exec_fence@basic-busy-default.html
>
>    
> #### Possible fixes ####
>
>    * igt@gem_exec_fence@basic-wait-default:
>      - fi-icl-u3:          [DMESG-WARN][91] ([fdo#107724]) -> [PASS][92] +2 similar issues
>     [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_exec_fence@basic-wait-default.html
>     [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_exec_fence@basic-wait-default.html
>
>    
>    {name}: This element is suppressed. This means it is ignored when computing
>            the status of the difference (SUCCESS, WARNING, or FAILURE).
>
>    [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
>    [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
>    [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
>    [fdo#109385]: https://bugs.freedesktop.org/show_bug.cgi?id=109385
>    [fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913
>
>
> Participating hosts (54 -> 46)
> ------------------------------
>
>    Additional (1): fi-cml-u2
>    Missing    (9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus
>
>
> Build changes
> -------------
>
>    * Linux: CI_DRM_6358 -> Patchwork_13438
>
>    CI_DRM_6358: 3454454b146cd9f684feb07ab9dff61dc875a022 @ git://anongit.freedesktop.org/gfx-ci/linux
>    IGT_5068: 15ad664534413628f06c0f172aac11598bfdb895 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>    Patchwork_13438: fbf9925e3e0220296c42260729dff5cc9d5d4c84 @ git://anongit.freedesktop.org/gfx-ci/linux
>
>
> == Linux commits ==
>
> fbf9925e3e02 drm/amdgpu: add independent DMA-buf import v7
> 13b9bef056c0 drm/amdgpu: add independent DMA-buf export v6
> b0d7a97cb362 drm/amdgpu: use allowed_domains for exported DMA-bufs
> 4624e4f46a05 drm/ttm: use the parent resv for ghost objects v2
> 8f8445fa6219 drm/ttm: remove the backing store if no placement is given
> 6d09a7de3969 dma-buf: add dynamic DMA-buf handling v13
>
> == Logs ==
>
> For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/

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

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

[Christian König]

Am 26.06.19 um 14:29 schrieb Daniel Vetter:
> On Wed, Jun 26, 2019 at 02:23:05PM +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
>> v13: add might_lock in appropriate places
> v14 with dmabuf->lock gone?

So just back from vacation and double checked that. It almost works but 
not quite yet because we still need the lock to protected against 
concurrent vmap operations.

And I'm not sure yet if we can use the reservation object there as well. 
Going to do try in a separate patch after this one landed.

>
> Also I looked at CI results and stuff, I guess you indeed didn't break the
> world because Chris Wilson has faught back struct_mutex far enough by now.
>
> Other issue is that since 2 weeks or so our CI started filtering all
> lockdep splats, so you need to dig into results yourself.
>
> btw on that, I think in the end the reservation_obj locking will at best
> be consistent between amdgpu and i915: I just remembered that all other
> ttm drivers have the mmap_sem vs resv_obj locking the wrong way round, and
> the trylock in ttm_bo_fault. So that part alone is hopeless, but I guess
> since radeon.ko is abandonware no one will ever fix that.
>
> So I think in the end it boils down to whether that's good enough to land
> it, or not.

Well can you give me an rb then? I mean at some point I have to push it 
to drm-misc-next.

Christian.

> -Daniel
>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/dma-buf/dma-buf.c | 183 ++++++++++++++++++++++++++++++++++++--
>>   include/linux/dma-buf.h   | 108 ++++++++++++++++++++--
>>   2 files changed, 277 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 6c15deb5d4ad..bd8611fa2cfa 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,31 @@ 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);
>> +		}
>> +	} else {
>> +		might_lock(&attach->dmabuf->resv->lock.base);
>> +	}
>> +
>>   	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 +938,43 @@ 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);
>> +	else
>> +		might_lock(&attach->dmabuf->resv->lock.base);
>> +
>>   	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 +1394,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
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
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 v13

[Daniel Vetter]

On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
> > On Wed, Jun 26, 2019 at 02:23:05PM +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
> > > v13: add might_lock in appropriate places
> > v14 with dmabuf->lock gone?
> 
> So just back from vacation and double checked that. It almost works but not
> quite yet because we still need the lock to protected against concurrent
> vmap operations.
> 
> And I'm not sure yet if we can use the reservation object there as well.
> Going to do try in a separate patch after this one landed.
> 
> > 
> > Also I looked at CI results and stuff, I guess you indeed didn't break the
> > world because Chris Wilson has faught back struct_mutex far enough by now.
> > 
> > Other issue is that since 2 weeks or so our CI started filtering all
> > lockdep splats, so you need to dig into results yourself.
> > 
> > btw on that, I think in the end the reservation_obj locking will at best
> > be consistent between amdgpu and i915: I just remembered that all other
> > ttm drivers have the mmap_sem vs resv_obj locking the wrong way round, and
> > the trylock in ttm_bo_fault. So that part alone is hopeless, but I guess
> > since radeon.ko is abandonware no one will ever fix that.
> > 
> > So I think in the end it boils down to whether that's good enough to land
> > it, or not.
> 
> Well can you give me an rb then? I mean at some point I have to push it to
> drm-misc-next.

Well my mail here preceeded the entire amdkfd eviction_fence discussion.
With that I'm not sure anymore, since we don't really need two approaches
of the same thing. And if the plan is to move amdkfd over from the
eviction_fence trick to using the invalidate callback here, then I think
we might need some clarifications on what exactly that means.
-Daniel

> 
> Christian.
> 
> > -Daniel
> > 
> > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > ---
> > >   drivers/dma-buf/dma-buf.c | 183 ++++++++++++++++++++++++++++++++++++--
> > >   include/linux/dma-buf.h   | 108 ++++++++++++++++++++--
> > >   2 files changed, 277 insertions(+), 14 deletions(-)
> > > 
> > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > index 6c15deb5d4ad..bd8611fa2cfa 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,31 @@ 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);
> > > +		}
> > > +	} else {
> > > +		might_lock(&attach->dmabuf->resv->lock.base);
> > > +	}
> > > +
> > >   	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 +938,43 @@ 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);
> > > +	else
> > > +		might_lock(&attach->dmabuf->resv->lock.base);
> > > +
> > >   	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 +1394,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
> > > 
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
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: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v13

[Koenig, Christian]

Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
>> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
>>> On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
>>> [SNIP]
>>> Also I looked at CI results and stuff, I guess you indeed didn't break the
>>> world because Chris Wilson has faught back struct_mutex far enough by now.
>>>
>>> Other issue is that since 2 weeks or so our CI started filtering all
>>> lockdep splats, so you need to dig into results yourself.
>>>
>>> btw on that, I think in the end the reservation_obj locking will at best
>>> be consistent between amdgpu and i915: I just remembered that all other
>>> ttm drivers have the mmap_sem vs resv_obj locking the wrong way round, and
>>> the trylock in ttm_bo_fault. So that part alone is hopeless, but I guess
>>> since radeon.ko is abandonware no one will ever fix that.
>>>
>>> So I think in the end it boils down to whether that's good enough to land
>>> it, or not.
>> Well can you give me an rb then? I mean at some point I have to push it to
>> drm-misc-next.
> Well my mail here preceeded the entire amdkfd eviction_fence discussion.
> With that I'm not sure anymore, since we don't really need two approaches
> of the same thing. And if the plan is to move amdkfd over from the
> eviction_fence trick to using the invalidate callback here, then I think
> we might need some clarifications on what exactly that means.

Mhm, I thought that this was orthogonal. I mean the invalidation 
callback for a buffer are independent from how the driver is going to 
use it in the end.

Or do you mean that we could use fences and save us from adding just 
another mechanism for the same signaling thing?

That could of course work, but I had the impression that you are not 
very in favor of that.

Christian.

> -Daniel
>
>> Christian.
>>
>>

_______________________________________________
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 v13

[Daniel Vetter]

On Fri, Jul 19, 2019 at 09:14:05AM +0000, Koenig, Christian wrote:
> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> > On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
> >> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
> >>> On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
> >>> [SNIP]
> >>> Also I looked at CI results and stuff, I guess you indeed didn't break the
> >>> world because Chris Wilson has faught back struct_mutex far enough by now.
> >>>
> >>> Other issue is that since 2 weeks or so our CI started filtering all
> >>> lockdep splats, so you need to dig into results yourself.
> >>>
> >>> btw on that, I think in the end the reservation_obj locking will at best
> >>> be consistent between amdgpu and i915: I just remembered that all other
> >>> ttm drivers have the mmap_sem vs resv_obj locking the wrong way round, and
> >>> the trylock in ttm_bo_fault. So that part alone is hopeless, but I guess
> >>> since radeon.ko is abandonware no one will ever fix that.
> >>>
> >>> So I think in the end it boils down to whether that's good enough to land
> >>> it, or not.
> >> Well can you give me an rb then? I mean at some point I have to push it to
> >> drm-misc-next.
> > Well my mail here preceeded the entire amdkfd eviction_fence discussion.
> > With that I'm not sure anymore, since we don't really need two approaches
> > of the same thing. And if the plan is to move amdkfd over from the
> > eviction_fence trick to using the invalidate callback here, then I think
> > we might need some clarifications on what exactly that means.
> 
> Mhm, I thought that this was orthogonal. I mean the invalidation 
> callback for a buffer are independent from how the driver is going to 
> use it in the end.
> 
> Or do you mean that we could use fences and save us from adding just 
> another mechanism for the same signaling thing?
> 
> That could of course work, but I had the impression that you are not 
> very in favor of that.

It won't, since you can either use the fence as the invalidate callback,
or as a fence (for implicit sync). But not both.

But I also don't think it's a good idea to have 2 invalidation mechanisms,
and since we do have one merged in-tree already would be good to proof
that the new one is up to the existing challenge.

For context: I spend way too much time reading ttm, amdgpu/kfd and i915-gem
code and my overall impression is that everyone's just running around in
opposite directions and it's one huge hairball of a mess. With a pretty
even distribution of equally "eek this is horrible" but also "wow this is
much better than what the other driver does". So that's why I'm even more
on the "are we sure this is the right thing" train.
-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: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v13

[Koenig, Christian]

Am 19.07.19 um 11:31 schrieb Daniel Vetter:
> On Fri, Jul 19, 2019 at 09:14:05AM +0000, Koenig, Christian wrote:
>> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
>>> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
>>>> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
>>>> [SNIP]
>>> Well my mail here preceeded the entire amdkfd eviction_fence discussion.
>>> With that I'm not sure anymore, since we don't really need two approaches
>>> of the same thing. And if the plan is to move amdkfd over from the
>>> eviction_fence trick to using the invalidate callback here, then I think
>>> we might need some clarifications on what exactly that means.
>> Mhm, I thought that this was orthogonal. I mean the invalidation
>> callback for a buffer are independent from how the driver is going to
>> use it in the end.
>>
>> Or do you mean that we could use fences and save us from adding just
>> another mechanism for the same signaling thing?
>>
>> That could of course work, but I had the impression that you are not
>> very in favor of that.
> It won't, since you can either use the fence as the invalidate callback,
> or as a fence (for implicit sync). But not both.

Why not both? I mean implicit sync is an artifact you need to handle 
separately anyway.

> But I also don't think it's a good idea to have 2 invalidation mechanisms,
> and since we do have one merged in-tree already would be good to proof
> that the new one is up to the existing challenge.

Ok, how to proceed then? Should I fix up the implicit syncing of fences 
first? I've go a couple of ideas for that as well.

This way we won't have any driver specific definition of what the fences 
in a reservation object mean any more.

> For context: I spend way too much time reading ttm, amdgpu/kfd and i915-gem
> code and my overall impression is that everyone's just running around in
> opposite directions and it's one huge hairball of a mess. With a pretty
> even distribution of equally "eek this is horrible" but also "wow this is
> much better than what the other driver does". So that's why I'm even more
> on the "are we sure this is the right thing" train.

Totally agree on that, but we should also not make the mistake we have 
seen on Windows to try to force all drivers into a common memory management.

That didn't worked out that well in the end and I would rather go down 
the route of trying to move logic into separate components and backing 
off into driver specific logic if we found that common stuff doesn't work.

Christian.

> -Daniel

_______________________________________________
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 v13

[Daniel Vetter]

On Fri, Jul 19, 2019 at 12:05:36PM +0000, Koenig, Christian wrote:
> Am 19.07.19 um 11:31 schrieb Daniel Vetter:
> > On Fri, Jul 19, 2019 at 09:14:05AM +0000, Koenig, Christian wrote:
> >> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> >>> On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
> >>>> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
> >>>> [SNIP]
> >>> Well my mail here preceeded the entire amdkfd eviction_fence discussion.
> >>> With that I'm not sure anymore, since we don't really need two approaches
> >>> of the same thing. And if the plan is to move amdkfd over from the
> >>> eviction_fence trick to using the invalidate callback here, then I think
> >>> we might need some clarifications on what exactly that means.
> >> Mhm, I thought that this was orthogonal. I mean the invalidation
> >> callback for a buffer are independent from how the driver is going to
> >> use it in the end.
> >>
> >> Or do you mean that we could use fences and save us from adding just
> >> another mechanism for the same signaling thing?
> >>
> >> That could of course work, but I had the impression that you are not
> >> very in favor of that.
> > It won't, since you can either use the fence as the invalidate callback,
> > or as a fence (for implicit sync). But not both.
> 
> Why not both? I mean implicit sync is an artifact you need to handle 
> separately anyway.

I guess I was unclear: We need something that does implicit sync and
dynamic migration both. And I think if you do the tricky auto-migrate on
first enable_signaling like amdkfd, then you can't really use the
reservation_object for implicit sync anymore.

> > But I also don't think it's a good idea to have 2 invalidation mechanisms,
> > and since we do have one merged in-tree already would be good to proof
> > that the new one is up to the existing challenge.
> 
> Ok, how to proceed then? Should I fix up the implicit syncing of fences 
> first? I've go a couple of ideas for that as well.
> 
> This way we won't have any driver specific definition of what the fences 
> in a reservation object mean any more.

Yeah I think moving forward with this series here is the best plan we
have. I just think at least a poc that the amdkfd eviction/migration logic
fits into this would be really good. I do think we'll need that anyway for
gpu drivers, there's a lot of noise to switch from supplying the working
set of BO on each CS to something more semi-permanently pinned (i.e. much
more the amdkfd model). Making sure dynamic dma-buf can cope with that
sounds like solid future proofing.

> > For context: I spend way too much time reading ttm, amdgpu/kfd and i915-gem
> > code and my overall impression is that everyone's just running around in
> > opposite directions and it's one huge hairball of a mess. With a pretty
> > even distribution of equally "eek this is horrible" but also "wow this is
> > much better than what the other driver does". So that's why I'm even more
> > on the "are we sure this is the right thing" train.
> 
> Totally agree on that, but we should also not make the mistake we have 
> seen on Windows to try to force all drivers into a common memory management.

Agreed that doesn't work either, see all the dri1 horrors.

> That didn't worked out that well in the end and I would rather go down 
> the route of trying to move logic into separate components and backing 
> off into driver specific logic if we found that common stuff doesn't work.

Yeah I think a bit more reviewing/following each another's stuff, and some
better alignment in the foundation of the underlying design is good. I'm
super stoked about Gerd's series for this reason. I'm also hoping that
hmm_mirror can help a lot for userptr (which is another area that just
freaks me out, and there I think amdgpu has the currently cleanest
approach with the hmm_mirror).

I think generally more helpers and less midlayers should help too. Aiming
for that with atomic was imo the best thing we've done on the display side
since the original kms stuff - the old legacy helpers where really not
modular and easy to extend at all, kinda similar to ttm on the memory
handling side.

I have no idea what best to do with all the existing ttm drivers, since
e.g. if we bake in the "bo lock nests within mmap_sem" rule, like amdgpu
and i915 need (and really it's the only way to make this work), then
everyone else is broken. Broken in the sense of lockdep splats at least,
which is kinda worse than just letting the legacy modeset drivers quietly
pass into the night without touching them.
-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: ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Daniel Vetter]

On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> Hi Daniel,
> 
> those fails look like something random to me and not related to my patch
> set. Correct?

First one I looked at has the reservation_obj all over:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html

So 5 second guees is ... probably real?

Note that with the entire lmem stuff going on right now there's massive
discussions about how we're doing resv_obj vs obj->mm.lock the wrong way
round in i915, so I'm not surprised at all that you managed to trip this.

The way I see it right now is that obj->mm.lock needs to be limited to
dealing with the i915 shrinker interactions only, and only for i915 native
objects. And for dma-bufs we need to make sure it's not anywhere in the
callchain. Unfortunately that's a massive refactor I guess ...
-Daniel

> 
> Christian.
> 
> Am 26.06.19 um 15:32 schrieb Patchwork:
> > == Series Details ==
> > 
> > Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13
> > URL   : https://patchwork.freedesktop.org/series/62777/
> > State : failure
> > 
> > == Summary ==
> > 
> > CI Bug Log - changes from CI_DRM_6358 -> Patchwork_13438
> > ====================================================
> > 
> > Summary
> > -------
> > 
> >    **FAILURE**
> > 
> >    Serious unknown changes coming with Patchwork_13438 absolutely need to be
> >    verified manually.
> >    If you think the reported changes have nothing to do with the changes
> >    introduced in Patchwork_13438, please notify your bug team to allow them
> >    to document this new failure mode, which will reduce false positives in CI.
> > 
> >    External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/
> > 
> > Possible new issues
> > -------------------
> > 
> >    Here are the unknown changes that may have been introduced in Patchwork_13438:
> > 
> > ### IGT changes ###
> > 
> > #### Possible regressions ####
> > 
> >    * igt@i915_selftest@live_contexts:
> >      - fi-kbl-7567u:       [PASS][1] -> [INCOMPLETE][2]
> >     [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7567u/igt@i915_selftest@live_contexts.html
> >     [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7567u/igt@i915_selftest@live_contexts.html
> > 
> >    * igt@i915_selftest@live_hugepages:
> >      - fi-skl-gvtdvm:      [PASS][3] -> [INCOMPLETE][4]
> >     [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html
> >     [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html
> > 
> > Known issues
> > ------------
> > 
> >    Here are the changes found in Patchwork_13438 that come from known issues:
> > 
> > ### IGT changes ###
> > 
> > #### Issues hit ####
> > 
> >    * igt@gem_basic@create-close:
> >      - fi-icl-u3:          [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
> >     [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_basic@create-close.html
> >     [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_basic@create-close.html
> > 
> >    * igt@gem_ctx_switch@basic-default:
> >      - fi-icl-guc:         [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#108569])
> >     [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-guc/igt@gem_ctx_switch@basic-default.html
> >     [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-guc/igt@gem_ctx_switch@basic-default.html
> > 
> >    * igt@gem_exec_create@basic:
> >      - fi-icl-u2:          [PASS][9] -> [INCOMPLETE][10] ([fdo#107713])
> >     [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u2/igt@gem_exec_create@basic.html
> >     [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u2/igt@gem_exec_create@basic.html
> > 
> >    * igt@gem_exec_fence@basic-busy-default:
> >      - fi-blb-e6850:       [PASS][11] -> [DMESG-WARN][12] ([fdo#110913 ])
> >     [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-blb-e6850/igt@gem_exec_fence@basic-busy-default.html
> >     [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-blb-e6850/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-cfl-guc:         [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 ])
> >     [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-guc/igt@gem_exec_fence@basic-busy-default.html
> >     [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-guc/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-skl-guc:         [PASS][15] -> [DMESG-WARN][16] ([fdo#110913 ])
> >     [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-guc/igt@gem_exec_fence@basic-busy-default.html
> >     [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-guc/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-apl-guc:         [PASS][17] -> [DMESG-WARN][18] ([fdo#110913 ])
> >     [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-apl-guc/igt@gem_exec_fence@basic-busy-default.html
> >     [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-apl-guc/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-hsw-4770r:       [PASS][19] -> [DMESG-WARN][20] ([fdo#110913 ])
> >     [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-4770r/igt@gem_exec_fence@basic-busy-default.html
> >     [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-4770r/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-glk-dsi:         [PASS][21] -> [DMESG-WARN][22] ([fdo#110913 ])
> >     [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-glk-dsi/igt@gem_exec_fence@basic-busy-default.html
> >     [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-glk-dsi/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-pnv-d510:        [PASS][23] -> [DMESG-WARN][24] ([fdo#110913 ])
> >     [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-pnv-d510/igt@gem_exec_fence@basic-busy-default.html
> >     [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-pnv-d510/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-skl-6600u:       [PASS][25] -> [DMESG-WARN][26] ([fdo#110913 ])
> >     [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6600u/igt@gem_exec_fence@basic-busy-default.html
> >     [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6600u/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-hsw-peppy:       [PASS][27] -> [DMESG-WARN][28] ([fdo#110913 ])
> >     [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-peppy/igt@gem_exec_fence@basic-busy-default.html
> >     [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-peppy/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-kbl-x1275:       [PASS][29] -> [DMESG-WARN][30] ([fdo#110913 ])
> >     [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-x1275/igt@gem_exec_fence@basic-busy-default.html
> >     [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-x1275/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-cfl-8700k:       [PASS][31] -> [DMESG-WARN][32] ([fdo#110913 ])
> >     [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-8700k/igt@gem_exec_fence@basic-busy-default.html
> >     [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-8700k/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-icl-dsi:         [PASS][33] -> [DMESG-WARN][34] ([fdo#110913 ])
> >     [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-dsi/igt@gem_exec_fence@basic-busy-default.html
> >     [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-dsi/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-bdw-5557u:       [PASS][35] -> [DMESG-WARN][36] ([fdo#110913 ])
> >     [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bdw-5557u/igt@gem_exec_fence@basic-busy-default.html
> >     [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bdw-5557u/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-kbl-7500u:       [PASS][37] -> [DMESG-WARN][38] ([fdo#110913 ])
> >     [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7500u/igt@gem_exec_fence@basic-busy-default.html
> >     [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7500u/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-kbl-8809g:       [PASS][39] -> [DMESG-WARN][40] ([fdo#110913 ])
> >     [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-8809g/igt@gem_exec_fence@basic-busy-default.html
> >     [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-8809g/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-bxt-dsi:         [PASS][41] -> [DMESG-WARN][42] ([fdo#109385] / [fdo#110913 ])
> >     [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bxt-dsi/igt@gem_exec_fence@basic-busy-default.html
> >     [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bxt-dsi/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-whl-u:           [PASS][43] -> [DMESG-WARN][44] ([fdo#110913 ])
> >     [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-whl-u/igt@gem_exec_fence@basic-busy-default.html
> >     [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-whl-u/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-skl-gvtdvm:      [PASS][45] -> [DMESG-WARN][46] ([fdo#110913 ])
> >     [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
> >     [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-cml-u:           [PASS][47] -> [DMESG-WARN][48] ([fdo#110913 ])
> >     [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
> >     [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-bsw-n3050:       [PASS][49] -> [DMESG-WARN][50] ([fdo#109385] / [fdo#110913 ])
> >     [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bsw-n3050/igt@gem_exec_fence@basic-busy-default.html
> >     [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bsw-n3050/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-ilk-650:         [PASS][51] -> [DMESG-WARN][52] ([fdo#110913 ])
> >     [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-ilk-650/igt@gem_exec_fence@basic-busy-default.html
> >     [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-ilk-650/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-hsw-4770:        [PASS][53] -> [DMESG-WARN][54] ([fdo#110913 ])
> >     [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-4770/igt@gem_exec_fence@basic-busy-default.html
> >     [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-4770/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-bdw-gvtdvm:      [PASS][55] -> [DMESG-WARN][56] ([fdo#110913 ])
> >     [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bdw-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
> >     [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bdw-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-skl-iommu:       [PASS][57] -> [DMESG-WARN][58] ([fdo#110913 ])
> >     [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-iommu/igt@gem_exec_fence@basic-busy-default.html
> >     [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-iommu/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-kbl-7567u:       [PASS][59] -> [DMESG-WARN][60] ([fdo#110913 ])
> >     [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7567u/igt@gem_exec_fence@basic-busy-default.html
> >     [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7567u/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-ivb-3770:        [PASS][61] -> [DMESG-WARN][62] ([fdo#110913 ])
> >     [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-ivb-3770/igt@gem_exec_fence@basic-busy-default.html
> >     [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-ivb-3770/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-snb-2520m:       [PASS][63] -> [DMESG-WARN][64] ([fdo#110913 ])
> >     [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-snb-2520m/igt@gem_exec_fence@basic-busy-default.html
> >     [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-snb-2520m/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-kbl-guc:         [PASS][65] -> [DMESG-WARN][66] ([fdo#110913 ])
> >     [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-guc/igt@gem_exec_fence@basic-busy-default.html
> >     [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-guc/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-bsw-kefka:       [PASS][67] -> [DMESG-WARN][68] ([fdo#109385] / [fdo#110913 ])
> >     [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bsw-kefka/igt@gem_exec_fence@basic-busy-default.html
> >     [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bsw-kefka/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-kbl-r:           [PASS][69] -> [DMESG-WARN][70] ([fdo#110913 ])
> >     [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-r/igt@gem_exec_fence@basic-busy-default.html
> >     [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-r/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-skl-6770hq:      [PASS][71] -> [DMESG-WARN][72] ([fdo#110913 ])
> >     [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6770hq/igt@gem_exec_fence@basic-busy-default.html
> >     [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6770hq/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-byt-n2820:       [PASS][73] -> [DMESG-WARN][74] ([fdo#110913 ])
> >     [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-byt-n2820/igt@gem_exec_fence@basic-busy-default.html
> >     [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-byt-n2820/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-cfl-8109u:       [PASS][75] -> [DMESG-WARN][76] ([fdo#110913 ])
> >     [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-8109u/igt@gem_exec_fence@basic-busy-default.html
> >     [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-8109u/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-icl-u3:          [PASS][77] -> [DMESG-WARN][78] ([fdo#110913 ])
> >     [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_exec_fence@basic-busy-default.html
> >     [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-byt-j1900:       [PASS][79] -> [DMESG-WARN][80] ([fdo#110913 ])
> >     [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-byt-j1900/igt@gem_exec_fence@basic-busy-default.html
> >     [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-byt-j1900/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-skl-6260u:       [PASS][81] -> [DMESG-WARN][82] ([fdo#110913 ])
> >     [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6260u/igt@gem_exec_fence@basic-busy-default.html
> >     [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6260u/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-bxt-j4205:       [PASS][83] -> [DMESG-WARN][84] ([fdo#109385] / [fdo#110913 ])
> >     [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bxt-j4205/igt@gem_exec_fence@basic-busy-default.html
> >     [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bxt-j4205/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-snb-2600:        [PASS][85] -> [DMESG-WARN][86] ([fdo#110913 ])
> >     [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-snb-2600/igt@gem_exec_fence@basic-busy-default.html
> >     [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-snb-2600/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-elk-e7500:       [PASS][87] -> [DMESG-WARN][88] ([fdo#110913 ])
> >     [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-elk-e7500/igt@gem_exec_fence@basic-busy-default.html
> >     [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-elk-e7500/igt@gem_exec_fence@basic-busy-default.html
> >      - fi-skl-6700k2:      [PASS][89] -> [DMESG-WARN][90] ([fdo#110913 ])
> >     [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6700k2/igt@gem_exec_fence@basic-busy-default.html
> >     [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6700k2/igt@gem_exec_fence@basic-busy-default.html
> > 
> > #### Possible fixes ####
> > 
> >    * igt@gem_exec_fence@basic-wait-default:
> >      - fi-icl-u3:          [DMESG-WARN][91] ([fdo#107724]) -> [PASS][92] +2 similar issues
> >     [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_exec_fence@basic-wait-default.html
> >     [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_exec_fence@basic-wait-default.html
> > 
> >    {name}: This element is suppressed. This means it is ignored when computing
> >            the status of the difference (SUCCESS, WARNING, or FAILURE).
> > 
> >    [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
> >    [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
> >    [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
> >    [fdo#109385]: https://bugs.freedesktop.org/show_bug.cgi?id=109385
> >    [fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913
> > 
> > 
> > Participating hosts (54 -> 46)
> > ------------------------------
> > 
> >    Additional (1): fi-cml-u2
> >    Missing    (9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus
> > 
> > 
> > Build changes
> > -------------
> > 
> >    * Linux: CI_DRM_6358 -> Patchwork_13438
> > 
> >    CI_DRM_6358: 3454454b146cd9f684feb07ab9dff61dc875a022 @ git://anongit.freedesktop.org/gfx-ci/linux
> >    IGT_5068: 15ad664534413628f06c0f172aac11598bfdb895 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> >    Patchwork_13438: fbf9925e3e0220296c42260729dff5cc9d5d4c84 @ git://anongit.freedesktop.org/gfx-ci/linux
> > 
> > 
> > == Linux commits ==
> > 
> > fbf9925e3e02 drm/amdgpu: add independent DMA-buf import v7
> > 13b9bef056c0 drm/amdgpu: add independent DMA-buf export v6
> > b0d7a97cb362 drm/amdgpu: use allowed_domains for exported DMA-bufs
> > 4624e4f46a05 drm/ttm: use the parent resv for ghost objects v2
> > 8f8445fa6219 drm/ttm: remove the backing store if no placement is given
> > 6d09a7de3969 dma-buf: add dynamic DMA-buf handling v13
> > 
> > == Logs ==
> > 
> > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/
> 

-- 
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: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v13

[Daniel Vetter]

On Wed, Jun 26, 2019 at 02:23:05PM +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
> v13: add might_lock in appropriate places
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>

I think I brought this up before, but new top-post for a clean start.

Use-case I have in mind is something like amdkfd's model, where you have a
list of buffers (per context or whatever) that you always need to have
present. Idea is to also use this for traditional CS for vk/gl, to cut
down on the buffer management overhead, but we'd still allow additional
buffers to be listed per-CS on top of that default working set.

This of course means no implicit sync anymore on these default buffers
(the point is to avoid touching every buffer on every CS, updating fences
would defeat that). That's why the CS can still list additional buffers,
the only reason for that is to add implicit sync fences. Those buffers
would be most likely in the default working set already.

Consequence is that I want the amdkfd model of "evict when needed, but
keep resident by default", but also working implicit fences. And it must
be doable without touching every bo on every CS. Listing possible
implementation options:

- the amdkfd trick doesn't work because it would break implicit fencing -
  any implicit sync would always result in the context getting
  preempted/evicted, which isn't great.

- we share the resv_obj between all the buffers in the default working set
  of a context, with unsharing/resharing the resv_obj if they enter/leave
  the default working set. That way there's only one resv_obj to update on
  each CS, and we can attach a new shared fence for every CS. Trouble is
  that this means a given buffer can only be part of one default working
  set, so all shared buffers would need to be listed again separately. Not
  so great if userspace has to deal with that fairly arbitrary limitation.

- we allow the ->move_notify callback to add new fences, which the
  exporter needs to wait on before it schedules the pipelined move. This
  also avoids the per-BO update on every CS, and it would allow buffers to
  be shared and to be in multiple default working sets. The downside is
  that ->move_notify needs to be able to cope with added fences, which
  means we might need to grow the shared fences array, which might fail
  with ENOMEM. Not great. We could fix this with some kind of permanent
  shared fence slot reservations (i.e. a reserved slot which outlives
  holding the reservation lock), but that might waste quite a bit of
  memory. Probably not real problem in the grand scheme of things. I think
  the fence itself can be preallocated per context, so that isn't the
  problem.

- same as above, but the new fence doesn't get added, but returned to the
  caller, and the exporter deals with the ENOMEM mess. Might not work
  since an importer could have a lot of contexts using a given object, and
  so would have a lot of fences to add.

- something entirely different?

Thoughts?

Cheers, Daniel

> ---
>  drivers/dma-buf/dma-buf.c | 183 ++++++++++++++++++++++++++++++++++++--
>  include/linux/dma-buf.h   | 108 ++++++++++++++++++++--
>  2 files changed, 277 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 6c15deb5d4ad..bd8611fa2cfa 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,31 @@ 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);
> +		}
> +	} else {
> +		might_lock(&attach->dmabuf->resv->lock.base);
> +	}
> +
>  	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 +938,43 @@ 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);
> +	else
> +		might_lock(&attach->dmabuf->resv->lock.base);
> +
>  	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 +1394,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
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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: [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v13

[Christian König]

Am 31.07.19 um 11:12 schrieb Daniel Vetter:
> [SNIP]
> I think I brought this up before, but new top-post for a clean start.
>
> Use-case I have in mind is something like amdkfd's model, where you have a
> list of buffers (per context or whatever) that you always need to have
> present. Idea is to also use this for traditional CS for vk/gl, to cut
> down on the buffer management overhead, but we'd still allow additional
> buffers to be listed per-CS on top of that default working set.
>
> This of course means no implicit sync anymore on these default buffers
> (the point is to avoid touching every buffer on every CS, updating fences
> would defeat that). That's why the CS can still list additional buffers,
> the only reason for that is to add implicit sync fences. Those buffers
> would be most likely in the default working set already.
>
> Consequence is that I want the amdkfd model of "evict when needed, but
> keep resident by default", but also working implicit fences. And it must
> be doable without touching every bo on every CS. Listing possible
> implementation options:
>
> - the amdkfd trick doesn't work because it would break implicit fencing -
>    any implicit sync would always result in the context getting
>    preempted/evicted, which isn't great.

I'm actually working on re-working implicit fencing towards better 
supporting this.

Basic idea is that you split up the fences in a reservation object into 
three categories:
1. Implicit sync on write.
2. Implicit sync on read.
3. No implicit sync at all.

This should not only help the KFD, but also with amdgpu command 
submission and things like page tables updates.

E.g. we need to fences for page tables updates around in reservation 
objects as well, but you really really really don't want any implicit 
synchronization with them :)

I think that having a consensus of the meaning of the fences in a 
reservation object will be rather fundamental for what we are planning 
to do here.

> - we share the resv_obj between all the buffers in the default working set
>    of a context, with unsharing/resharing the resv_obj if they enter/leave
>    the default working set. That way there's only one resv_obj to update on
>    each CS, and we can attach a new shared fence for every CS. Trouble is
>    that this means a given buffer can only be part of one default working
>    set, so all shared buffers would need to be listed again separately. Not
>    so great if userspace has to deal with that fairly arbitrary limitation.

Yeah, that is exactly what we do with the per VM BOs in amdgpu.

The limitation that you have only one working set actually turned out to 
be not a limitation at all, but rather seen as something welcomed by our 
Vulkan guys.

I also don't really see a way to have an implementation with good 
performance where BOs can be in multiple working sets at the same time.

> - we allow the ->move_notify callback to add new fences, which the
>    exporter needs to wait on before it schedules the pipelined move. This
>    also avoids the per-BO update on every CS, and it would allow buffers to
>    be shared and to be in multiple default working sets. The downside is
>    that ->move_notify needs to be able to cope with added fences, which
>    means we might need to grow the shared fences array, which might fail
>    with ENOMEM. Not great. We could fix this with some kind of permanent
>    shared fence slot reservations (i.e. a reserved slot which outlives
>    holding the reservation lock), but that might waste quite a bit of
>    memory. Probably not real problem in the grand scheme of things. I think
>    the fence itself can be preallocated per context, so that isn't the
>    problem.

Well the ENOMEM problem is the least of the problems with this approach. 
You can still block for the fence which you wanted to add.

The real problem is that you can't tell if a BO is busy or not by just 
looking at its current fences.

In other words when you stop adding fences you also want to stop moving 
them individually on the LRU.

When the memory management evicts one BO you essentially kick out a 
whole process/working set.

So when you want to kick out the next BO you actually want to do this 
for BOs which now became available anyway.

That approach won't work with the move_notify callback.

> - same as above, but the new fence doesn't get added, but returned to the
>    caller, and the exporter deals with the ENOMEM mess. Might not work
>    since an importer could have a lot of contexts using a given object, and
>    so would have a lot of fences to add.

I don't think that this will work.

See you not only need to be able to add the fence to the BO currently 
evicted, but also to all other BO in your process/working set.

Additional to that moving the ENOMEM handling from the importer to the 
exporter sounds as helpful as adding another layer of abstraction :)

Regards,
Christian.

>
> - something entirely different?
>
> Thoughts?
>
> Cheers, Daniel
>
>> ---
>>   drivers/dma-buf/dma-buf.c | 183 ++++++++++++++++++++++++++++++++++++--
>>   include/linux/dma-buf.h   | 108 ++++++++++++++++++++--
>>   2 files changed, 277 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 6c15deb5d4ad..bd8611fa2cfa 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,31 @@ 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);
>> +		}
>> +	} else {
>> +		might_lock(&attach->dmabuf->resv->lock.base);
>> +	}
>> +
>>   	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 +938,43 @@ 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);
>> +	else
>> +		might_lock(&attach->dmabuf->resv->lock.base);
>> +
>>   	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 +1394,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
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
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 v13

[Daniel Vetter]

On Wed, Jul 31, 2019 at 11:44 AM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> Am 31.07.19 um 11:12 schrieb Daniel Vetter:
> > [SNIP]
> > I think I brought this up before, but new top-post for a clean start.
> >
> > Use-case I have in mind is something like amdkfd's model, where you have a
> > list of buffers (per context or whatever) that you always need to have
> > present. Idea is to also use this for traditional CS for vk/gl, to cut
> > down on the buffer management overhead, but we'd still allow additional
> > buffers to be listed per-CS on top of that default working set.
> >
> > This of course means no implicit sync anymore on these default buffers
> > (the point is to avoid touching every buffer on every CS, updating fences
> > would defeat that). That's why the CS can still list additional buffers,
> > the only reason for that is to add implicit sync fences. Those buffers
> > would be most likely in the default working set already.
> >
> > Consequence is that I want the amdkfd model of "evict when needed, but
> > keep resident by default", but also working implicit fences. And it must
> > be doable without touching every bo on every CS. Listing possible
> > implementation options:
> >
> > - the amdkfd trick doesn't work because it would break implicit fencing -
> >    any implicit sync would always result in the context getting
> >    preempted/evicted, which isn't great.
>
> I'm actually working on re-working implicit fencing towards better
> supporting this.
>
> Basic idea is that you split up the fences in a reservation object into
> three categories:
> 1. Implicit sync on write.
> 2. Implicit sync on read.
> 3. No implicit sync at all.

Not really sure what you want to do here ... implicit sync is opt-in
(or opt-out flag if you need to keep CS backwards compat) per BO/CS.
At least when we discussed this forever at some XDCs consensus was
that storing the implicit sync mode on the BO is not going to work.

> This should not only help the KFD, but also with amdgpu command
> submission and things like page tables updates.
>
> E.g. we need to fences for page tables updates around in reservation
> objects as well, but you really really really don't want any implicit
> synchronization with them :)

Why do you even try to do implicit sync with your pagetables? How can
your pagetables even get anywhere near where implicit sync matters?
I'm confused ... If it's because ttm doesn't allow you to override the
eviction order because it's a midlayer I think the correct fix is to
demidlayer.

> I think that having a consensus of the meaning of the fences in a
> reservation object will be rather fundamental for what we are planning
> to do here.

Yeah that I can agree on.

> > - we share the resv_obj between all the buffers in the default working set
> >    of a context, with unsharing/resharing the resv_obj if they enter/leave
> >    the default working set. That way there's only one resv_obj to update on
> >    each CS, and we can attach a new shared fence for every CS. Trouble is
> >    that this means a given buffer can only be part of one default working
> >    set, so all shared buffers would need to be listed again separately. Not
> >    so great if userspace has to deal with that fairly arbitrary limitation.
>
> Yeah, that is exactly what we do with the per VM BOs in amdgpu.
>
> The limitation that you have only one working set actually turned out to
> be not a limitation at all, but rather seen as something welcomed by our
> Vulkan guys.

We have per-ctx vms in i915, but I guess even for those sharing will be limited.

> I also don't really see a way to have an implementation with good
> performance where BOs can be in multiple working sets at the same time.
>
> > - we allow the ->move_notify callback to add new fences, which the
> >    exporter needs to wait on before it schedules the pipelined move. This
> >    also avoids the per-BO update on every CS, and it would allow buffers to
> >    be shared and to be in multiple default working sets. The downside is
> >    that ->move_notify needs to be able to cope with added fences, which
> >    means we might need to grow the shared fences array, which might fail
> >    with ENOMEM. Not great. We could fix this with some kind of permanent
> >    shared fence slot reservations (i.e. a reserved slot which outlives
> >    holding the reservation lock), but that might waste quite a bit of
> >    memory. Probably not real problem in the grand scheme of things. I think
> >    the fence itself can be preallocated per context, so that isn't the
> >    problem.
>
> Well the ENOMEM problem is the least of the problems with this approach.
> You can still block for the fence which you wanted to add.
>
> The real problem is that you can't tell if a BO is busy or not by just
> looking at its current fences.
>
> In other words when you stop adding fences you also want to stop moving
> them individually on the LRU.

Well yeah, otherwise you're back a per BO overhead on CS. That's kinda
obvious. But also not sure why this matters, since atm we don't have
any proposed means to pass LRU updates through dma-buf. So exporter
(even with dynamic dma-buf) has to pessimistically assume already that
the exported BO is more busy than what the LRU position suggests, and
evict them later on. If we also need to funnel LRU updates over
dma-buf, then that's another beast entirely (and probably not what we
want to do at all).

Also if you don't want to stall, then just reject after ->move_notify
wherethere the bo is still idle, and give up if so. Or we can add a
counter to indicate a bo needs to be considered busy.

> When the memory management evicts one BO you essentially kick out a
> whole process/working set.
>
> So when you want to kick out the next BO you actually want to do this
> for BOs which now became available anyway.
>
> That approach won't work with the move_notify callback.

So essentially we don't just want move_notify, but also full LRU information?

> > - same as above, but the new fence doesn't get added, but returned to the
> >    caller, and the exporter deals with the ENOMEM mess. Might not work
> >    since an importer could have a lot of contexts using a given object, and
> >    so would have a lot of fences to add.
>
> I don't think that this will work.
>
> See you not only need to be able to add the fence to the BO currently
> evicted, but also to all other BO in your process/working set.
>
> Additional to that moving the ENOMEM handling from the importer to the
> exporter sounds as helpful as adding another layer of abstraction :)

You can go and pick a different victim to evict, or just give up
(there's not much you can do with ENOMEM). Instead of data corruption
because you're not waiting for a fence you should be waiting on.
-Daniel

>
> Regards,
> Christian.
>
> >
> > - something entirely different?
> >
> > Thoughts?
> >
> > Cheers, Daniel
> >
> >> ---
> >>   drivers/dma-buf/dma-buf.c | 183 ++++++++++++++++++++++++++++++++++++--
> >>   include/linux/dma-buf.h   | 108 ++++++++++++++++++++--
> >>   2 files changed, 277 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >> index 6c15deb5d4ad..bd8611fa2cfa 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,31 @@ 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);
> >> +            }
> >> +    } else {
> >> +            might_lock(&attach->dmabuf->resv->lock.base);
> >> +    }
> >> +
> >>      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 +938,43 @@ 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);
> >> +    else
> >> +            might_lock(&attach->dmabuf->resv->lock.base);
> >> +
> >>      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 +1394,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
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>


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

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

[Christian König]

Am 31.07.19 um 12:39 schrieb Daniel Vetter:
> On Wed, Jul 31, 2019 at 11:44 AM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>> Am 31.07.19 um 11:12 schrieb Daniel Vetter:
>>> [SNIP]
>>> I think I brought this up before, but new top-post for a clean start.
>>>
>>> Use-case I have in mind is something like amdkfd's model, where you have a
>>> list of buffers (per context or whatever) that you always need to have
>>> present. Idea is to also use this for traditional CS for vk/gl, to cut
>>> down on the buffer management overhead, but we'd still allow additional
>>> buffers to be listed per-CS on top of that default working set.
>>>
>>> This of course means no implicit sync anymore on these default buffers
>>> (the point is to avoid touching every buffer on every CS, updating fences
>>> would defeat that). That's why the CS can still list additional buffers,
>>> the only reason for that is to add implicit sync fences. Those buffers
>>> would be most likely in the default working set already.
>>>
>>> Consequence is that I want the amdkfd model of "evict when needed, but
>>> keep resident by default", but also working implicit fences. And it must
>>> be doable without touching every bo on every CS. Listing possible
>>> implementation options:
>>>
>>> - the amdkfd trick doesn't work because it would break implicit fencing -
>>>     any implicit sync would always result in the context getting
>>>     preempted/evicted, which isn't great.
>> I'm actually working on re-working implicit fencing towards better
>> supporting this.
>>
>> Basic idea is that you split up the fences in a reservation object into
>> three categories:
>> 1. Implicit sync on write.
>> 2. Implicit sync on read.
>> 3. No implicit sync at all.
> Not really sure what you want to do here ... implicit sync is opt-in
> (or opt-out flag if you need to keep CS backwards compat) per BO/CS.
> At least when we discussed this forever at some XDCs consensus was
> that storing the implicit sync mode on the BO is not going to work.

Well that's exactly what we are doing for amdgpu and this is working 
perfectly. See flag AMDGPU_GEM_CREATE_EXPLICIT_SYNC.

>> This should not only help the KFD, but also with amdgpu command
>> submission and things like page tables updates.
>>
>> E.g. we need to fences for page tables updates around in reservation
>> objects as well, but you really really really don't want any implicit
>> synchronization with them :)
> Why do you even try to do implicit sync with your pagetables? How can
> your pagetables even get anywhere near where implicit sync matters?

When you unmap a BO from a page table the BO needs to stay in the same 
place until the unmap operation is completed.

Otherwise you open up a short window where a process could access memory 
which doesn't belongs to the process.

This unmap operation is usually an SDMA operation and nobody except for 
the memory management needs to take this into account.

>>> - we share the resv_obj between all the buffers in the default working set
>>>     of a context, with unsharing/resharing the resv_obj if they enter/leave
>>>     the default working set. That way there's only one resv_obj to update on
>>>     each CS, and we can attach a new shared fence for every CS. Trouble is
>>>     that this means a given buffer can only be part of one default working
>>>     set, so all shared buffers would need to be listed again separately. Not
>>>     so great if userspace has to deal with that fairly arbitrary limitation.
>> Yeah, that is exactly what we do with the per VM BOs in amdgpu.
>>
>> The limitation that you have only one working set actually turned out to
>> be not a limitation at all, but rather seen as something welcomed by our
>> Vulkan guys.
> We have per-ctx vms in i915, but I guess even for those sharing will be limited.

In amdgpu we had this funky stuff with bo lists which should represent 
the resources used for a command submission.

But after actually talking to the Vulkan and other userspace guys we 
completely deprecated that.

We settled on having per process resources which are always valid and a 
dynamic list of resources you send to the kernel with each command 
submission.

>> I also don't really see a way to have an implementation with good
>> performance where BOs can be in multiple working sets at the same time.
>>
>>> - we allow the ->move_notify callback to add new fences, which the
>>>     exporter needs to wait on before it schedules the pipelined move. This
>>>     also avoids the per-BO update on every CS, and it would allow buffers to
>>>     be shared and to be in multiple default working sets. The downside is
>>>     that ->move_notify needs to be able to cope with added fences, which
>>>     means we might need to grow the shared fences array, which might fail
>>>     with ENOMEM. Not great. We could fix this with some kind of permanent
>>>     shared fence slot reservations (i.e. a reserved slot which outlives
>>>     holding the reservation lock), but that might waste quite a bit of
>>>     memory. Probably not real problem in the grand scheme of things. I think
>>>     the fence itself can be preallocated per context, so that isn't the
>>>     problem.
>> Well the ENOMEM problem is the least of the problems with this approach.
>> You can still block for the fence which you wanted to add.
>>
>> The real problem is that you can't tell if a BO is busy or not by just
>> looking at its current fences.
>>
>> In other words when you stop adding fences you also want to stop moving
>> them individually on the LRU.
> Well yeah, otherwise you're back a per BO overhead on CS. That's kinda
> obvious. But also not sure why this matters, since atm we don't have
> any proposed means to pass LRU updates through dma-buf. So exporter
> (even with dynamic dma-buf) has to pessimistically assume already that
> the exported BO is more busy than what the LRU position suggests, and
> evict them later on. If we also need to funnel LRU updates over
> dma-buf, then that's another beast entirely (and probably not what we
> want to do at all).

Yeah, that's a really good point for DMA-buf.

But I'm thinking a bit wider here. Essentially we need some ideas which 
not only work for DMA-buf, but also inside the same driver.

> Also if you don't want to stall, then just reject after ->move_notify
> wherethere the bo is still idle, and give up if so. Or we can add a
> counter to indicate a bo needs to be considered busy.
>
>> When the memory management evicts one BO you essentially kick out a
>> whole process/working set.
>>
>> So when you want to kick out the next BO you actually want to do this
>> for BOs which now became available anyway.
>>
>> That approach won't work with the move_notify callback.
> So essentially we don't just want move_notify, but also full LRU information?

At least for DMA-buf I was trying to avoid that. But in the long term it 
might be necessary, yes.

>>> - same as above, but the new fence doesn't get added, but returned to the
>>>     caller, and the exporter deals with the ENOMEM mess. Might not work
>>>     since an importer could have a lot of contexts using a given object, and
>>>     so would have a lot of fences to add.
>> I don't think that this will work.
>>
>> See you not only need to be able to add the fence to the BO currently
>> evicted, but also to all other BO in your process/working set.
>>
>> Additional to that moving the ENOMEM handling from the importer to the
>> exporter sounds as helpful as adding another layer of abstraction :)
> You can go and pick a different victim to evict, or just give up
> (there's not much you can do with ENOMEM). Instead of data corruption
> because you're not waiting for a fence you should be waiting on.

Ok, but you can as well return -ENOMEM from the move_notify callback.

What I wanted to say is that by returning the error code you are still 
more flexible than returning the fence. On other words returning the 
fence doesn't seem to help...

Christian.

> -Daniel
>
>> Regards,
>> Christian.
>>
>>> - something entirely different?
>>>
>>> Thoughts?
>>>
>>> Cheers, Daniel
>>>

_______________________________________________
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 v13

[Daniel Vetter]

On Wed, Jul 31, 2019 at 1:19 PM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> Am 31.07.19 um 12:39 schrieb Daniel Vetter:
> > On Wed, Jul 31, 2019 at 11:44 AM Christian König
> > <ckoenig.leichtzumerken@gmail.com> wrote:
> >> Am 31.07.19 um 11:12 schrieb Daniel Vetter:
> >>> [SNIP]
> >>> I think I brought this up before, but new top-post for a clean start.
> >>>
> >>> Use-case I have in mind is something like amdkfd's model, where you have a
> >>> list of buffers (per context or whatever) that you always need to have
> >>> present. Idea is to also use this for traditional CS for vk/gl, to cut
> >>> down on the buffer management overhead, but we'd still allow additional
> >>> buffers to be listed per-CS on top of that default working set.
> >>>
> >>> This of course means no implicit sync anymore on these default buffers
> >>> (the point is to avoid touching every buffer on every CS, updating fences
> >>> would defeat that). That's why the CS can still list additional buffers,
> >>> the only reason for that is to add implicit sync fences. Those buffers
> >>> would be most likely in the default working set already.
> >>>
> >>> Consequence is that I want the amdkfd model of "evict when needed, but
> >>> keep resident by default", but also working implicit fences. And it must
> >>> be doable without touching every bo on every CS. Listing possible
> >>> implementation options:
> >>>
> >>> - the amdkfd trick doesn't work because it would break implicit fencing -
> >>>     any implicit sync would always result in the context getting
> >>>     preempted/evicted, which isn't great.
> >> I'm actually working on re-working implicit fencing towards better
> >> supporting this.
> >>
> >> Basic idea is that you split up the fences in a reservation object into
> >> three categories:
> >> 1. Implicit sync on write.
> >> 2. Implicit sync on read.
> >> 3. No implicit sync at all.
> > Not really sure what you want to do here ... implicit sync is opt-in
> > (or opt-out flag if you need to keep CS backwards compat) per BO/CS.
> > At least when we discussed this forever at some XDCs consensus was
> > that storing the implicit sync mode on the BO is not going to work.
>
> Well that's exactly what we are doing for amdgpu and this is working
> perfectly. See flag AMDGPU_GEM_CREATE_EXPLICIT_SYNC.

Iirc the example where you can't decide at creation time is
EGL-on-gbm. If you run on something like X, you need implicit sync. If
you run on Android, you need explicit sync. And the only way to figure
that out is watch whether your compositor uses the explicit sync
android extension And from a very quick look in mesa this seems only
wired up for radv and not classic GL, so I guess you didn't take that
case into account?

For vk (which this is for) the create-time flag obviously works,
because vk is generally not totally crazy.

> >> This should not only help the KFD, but also with amdgpu command
> >> submission and things like page tables updates.
> >>
> >> E.g. we need to fences for page tables updates around in reservation
> >> objects as well, but you really really really don't want any implicit
> >> synchronization with them :)
> > Why do you even try to do implicit sync with your pagetables? How can
> > your pagetables even get anywhere near where implicit sync matters?
>
> When you unmap a BO from a page table the BO needs to stay in the same
> place until the unmap operation is completed.
>
> Otherwise you open up a short window where a process could access memory
> which doesn't belongs to the process.
>
> This unmap operation is usually an SDMA operation and nobody except for
> the memory management needs to take this into account.
>
> >>> - we share the resv_obj between all the buffers in the default working set
> >>>     of a context, with unsharing/resharing the resv_obj if they enter/leave
> >>>     the default working set. That way there's only one resv_obj to update on
> >>>     each CS, and we can attach a new shared fence for every CS. Trouble is
> >>>     that this means a given buffer can only be part of one default working
> >>>     set, so all shared buffers would need to be listed again separately. Not
> >>>     so great if userspace has to deal with that fairly arbitrary limitation.
> >> Yeah, that is exactly what we do with the per VM BOs in amdgpu.
> >>
> >> The limitation that you have only one working set actually turned out to
> >> be not a limitation at all, but rather seen as something welcomed by our
> >> Vulkan guys.
> > We have per-ctx vms in i915, but I guess even for those sharing will be limited.
>
> In amdgpu we had this funky stuff with bo lists which should represent
> the resources used for a command submission.
>
> But after actually talking to the Vulkan and other userspace guys we
> completely deprecated that.
>
> We settled on having per process resources which are always valid and a
> dynamic list of resources you send to the kernel with each command
> submission.

The per-ctx vm is for arb_robustness, we had a small chat with Michel
on irc. I still think that makes sense. And having the list of
default-bound objects per-vm also makes sense, so I guess we'll end up
with multiple of those per drm file private. Multiple list entirely
decoupled from the vm don't make sense to me.

> >> I also don't really see a way to have an implementation with good
> >> performance where BOs can be in multiple working sets at the same time.
> >>
> >>> - we allow the ->move_notify callback to add new fences, which the
> >>>     exporter needs to wait on before it schedules the pipelined move. This
> >>>     also avoids the per-BO update on every CS, and it would allow buffers to
> >>>     be shared and to be in multiple default working sets. The downside is
> >>>     that ->move_notify needs to be able to cope with added fences, which
> >>>     means we might need to grow the shared fences array, which might fail
> >>>     with ENOMEM. Not great. We could fix this with some kind of permanent
> >>>     shared fence slot reservations (i.e. a reserved slot which outlives
> >>>     holding the reservation lock), but that might waste quite a bit of
> >>>     memory. Probably not real problem in the grand scheme of things. I think
> >>>     the fence itself can be preallocated per context, so that isn't the
> >>>     problem.
> >> Well the ENOMEM problem is the least of the problems with this approach.
> >> You can still block for the fence which you wanted to add.
> >>
> >> The real problem is that you can't tell if a BO is busy or not by just
> >> looking at its current fences.
> >>
> >> In other words when you stop adding fences you also want to stop moving
> >> them individually on the LRU.
> > Well yeah, otherwise you're back a per BO overhead on CS. That's kinda
> > obvious. But also not sure why this matters, since atm we don't have
> > any proposed means to pass LRU updates through dma-buf. So exporter
> > (even with dynamic dma-buf) has to pessimistically assume already that
> > the exported BO is more busy than what the LRU position suggests, and
> > evict them later on. If we also need to funnel LRU updates over
> > dma-buf, then that's another beast entirely (and probably not what we
> > want to do at all).
>
> Yeah, that's a really good point for DMA-buf.
>
> But I'm thinking a bit wider here. Essentially we need some ideas which
> not only work for DMA-buf, but also inside the same driver.

So we need at least a little bit of LRU information. You seem to want
at least business, maybe we could also add a last_used timestamp to
the reservation object. That way if you travel the LRU and it's
backwards, you know you need to delay that one. Of course this only
works if we can somehow share that information, either with a shared
resv_obj (like amdgpu does for the default bound obj), or the shared
eviction fence amdkfd uses.

I'm pondering some ideas what that could look like now, but nothing
worth typing down just yet.

> > Also if you don't want to stall, then just reject after ->move_notify
> > wherethere the bo is still idle, and give up if so. Or we can add a
> > counter to indicate a bo needs to be considered busy.
> >
> >> When the memory management evicts one BO you essentially kick out a
> >> whole process/working set.
> >>
> >> So when you want to kick out the next BO you actually want to do this
> >> for BOs which now became available anyway.
> >>
> >> That approach won't work with the move_notify callback.
> > So essentially we don't just want move_notify, but also full LRU information?
>
> At least for DMA-buf I was trying to avoid that. But in the long term it
> might be necessary, yes.
>
> >>> - same as above, but the new fence doesn't get added, but returned to the
> >>>     caller, and the exporter deals with the ENOMEM mess. Might not work
> >>>     since an importer could have a lot of contexts using a given object, and
> >>>     so would have a lot of fences to add.
> >> I don't think that this will work.
> >>
> >> See you not only need to be able to add the fence to the BO currently
> >> evicted, but also to all other BO in your process/working set.
> >>
> >> Additional to that moving the ENOMEM handling from the importer to the
> >> exporter sounds as helpful as adding another layer of abstraction :)
> > You can go and pick a different victim to evict, or just give up
> > (there's not much you can do with ENOMEM). Instead of data corruption
> > because you're not waiting for a fence you should be waiting on.
>
> Ok, but you can as well return -ENOMEM from the move_notify callback.
>
> What I wanted to say is that by returning the error code you are still
> more flexible than returning the fence. On other words returning the
> fence doesn't seem to help...

Yeah agreed, error code should be good enough for this. But still
feels like a gross hack, not a proper solution.
-Daniel

>
> Christian.
>
> > -Daniel
> >
> >> Regards,
> >> Christian.
> >>
> >>> - something entirely different?
> >>>
> >>> Thoughts?
> >>>
> >>> 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: ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Daniel Vetter]

On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> > Hi Daniel,
> > 
> > those fails look like something random to me and not related to my patch
> > set. Correct?
> 
> First one I looked at has the reservation_obj all over:
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
> 
> So 5 second guees is ... probably real?
> 
> Note that with the entire lmem stuff going on right now there's massive
> discussions about how we're doing resv_obj vs obj->mm.lock the wrong way
> round in i915, so I'm not surprised at all that you managed to trip this.
> 
> The way I see it right now is that obj->mm.lock needs to be limited to
> dealing with the i915 shrinker interactions only, and only for i915 native
> objects. And for dma-bufs we need to make sure it's not anywhere in the
> callchain. Unfortunately that's a massive refactor I guess ...

Thought about this some more, aside from just breaking i915 or waiting
until it's refactored (Both not awesome) I think the only option is get
back to the original caching. And figure out whether we really need to
take the direction into account for that, or whether upgrading to
bidirectional unconditionally won't be ok. I think there's only really two
cases where this matters:

- display drivers using the cma/dma_alloc helpers. Everything is allocated
  fully coherent, cpu side wc, no flushing.

- Everyone else (on platforms where there's actually some flushing going
  on) is for rendering gpus, and those always map bidirectional and want
  the mapping cached for as long as possible.

With that we could go back to creating the cached mapping at attach time
and avoid inflicting the reservation object lock to places that would keel
over.

Thoughts?
-Daniel

> -Daniel
> 
> > 
> > Christian.
> > 
> > Am 26.06.19 um 15:32 schrieb Patchwork:
> > > == Series Details ==
> > > 
> > > Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13
> > > URL   : https://patchwork.freedesktop.org/series/62777/
> > > State : failure
> > > 
> > > == Summary ==
> > > 
> > > CI Bug Log - changes from CI_DRM_6358 -> Patchwork_13438
> > > ====================================================
> > > 
> > > Summary
> > > -------
> > > 
> > >    **FAILURE**
> > > 
> > >    Serious unknown changes coming with Patchwork_13438 absolutely need to be
> > >    verified manually.
> > >    If you think the reported changes have nothing to do with the changes
> > >    introduced in Patchwork_13438, please notify your bug team to allow them
> > >    to document this new failure mode, which will reduce false positives in CI.
> > > 
> > >    External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/
> > > 
> > > Possible new issues
> > > -------------------
> > > 
> > >    Here are the unknown changes that may have been introduced in Patchwork_13438:
> > > 
> > > ### IGT changes ###
> > > 
> > > #### Possible regressions ####
> > > 
> > >    * igt@i915_selftest@live_contexts:
> > >      - fi-kbl-7567u:       [PASS][1] -> [INCOMPLETE][2]
> > >     [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7567u/igt@i915_selftest@live_contexts.html
> > >     [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7567u/igt@i915_selftest@live_contexts.html
> > > 
> > >    * igt@i915_selftest@live_hugepages:
> > >      - fi-skl-gvtdvm:      [PASS][3] -> [INCOMPLETE][4]
> > >     [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html
> > >     [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html
> > > 
> > > Known issues
> > > ------------
> > > 
> > >    Here are the changes found in Patchwork_13438 that come from known issues:
> > > 
> > > ### IGT changes ###
> > > 
> > > #### Issues hit ####
> > > 
> > >    * igt@gem_basic@create-close:
> > >      - fi-icl-u3:          [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
> > >     [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_basic@create-close.html
> > >     [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_basic@create-close.html
> > > 
> > >    * igt@gem_ctx_switch@basic-default:
> > >      - fi-icl-guc:         [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#108569])
> > >     [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-guc/igt@gem_ctx_switch@basic-default.html
> > >     [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-guc/igt@gem_ctx_switch@basic-default.html
> > > 
> > >    * igt@gem_exec_create@basic:
> > >      - fi-icl-u2:          [PASS][9] -> [INCOMPLETE][10] ([fdo#107713])
> > >     [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u2/igt@gem_exec_create@basic.html
> > >     [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u2/igt@gem_exec_create@basic.html
> > > 
> > >    * igt@gem_exec_fence@basic-busy-default:
> > >      - fi-blb-e6850:       [PASS][11] -> [DMESG-WARN][12] ([fdo#110913 ])
> > >     [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-blb-e6850/igt@gem_exec_fence@basic-busy-default.html
> > >     [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-blb-e6850/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-cfl-guc:         [PASS][13] -> [DMESG-WARN][14] ([fdo#110913 ])
> > >     [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-guc/igt@gem_exec_fence@basic-busy-default.html
> > >     [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-guc/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-skl-guc:         [PASS][15] -> [DMESG-WARN][16] ([fdo#110913 ])
> > >     [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-guc/igt@gem_exec_fence@basic-busy-default.html
> > >     [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-guc/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-apl-guc:         [PASS][17] -> [DMESG-WARN][18] ([fdo#110913 ])
> > >     [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-apl-guc/igt@gem_exec_fence@basic-busy-default.html
> > >     [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-apl-guc/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-hsw-4770r:       [PASS][19] -> [DMESG-WARN][20] ([fdo#110913 ])
> > >     [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-4770r/igt@gem_exec_fence@basic-busy-default.html
> > >     [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-4770r/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-glk-dsi:         [PASS][21] -> [DMESG-WARN][22] ([fdo#110913 ])
> > >     [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-glk-dsi/igt@gem_exec_fence@basic-busy-default.html
> > >     [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-glk-dsi/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-pnv-d510:        [PASS][23] -> [DMESG-WARN][24] ([fdo#110913 ])
> > >     [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-pnv-d510/igt@gem_exec_fence@basic-busy-default.html
> > >     [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-pnv-d510/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-skl-6600u:       [PASS][25] -> [DMESG-WARN][26] ([fdo#110913 ])
> > >     [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6600u/igt@gem_exec_fence@basic-busy-default.html
> > >     [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6600u/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-hsw-peppy:       [PASS][27] -> [DMESG-WARN][28] ([fdo#110913 ])
> > >     [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-peppy/igt@gem_exec_fence@basic-busy-default.html
> > >     [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-peppy/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-kbl-x1275:       [PASS][29] -> [DMESG-WARN][30] ([fdo#110913 ])
> > >     [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-x1275/igt@gem_exec_fence@basic-busy-default.html
> > >     [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-x1275/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-cfl-8700k:       [PASS][31] -> [DMESG-WARN][32] ([fdo#110913 ])
> > >     [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-8700k/igt@gem_exec_fence@basic-busy-default.html
> > >     [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-8700k/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-icl-dsi:         [PASS][33] -> [DMESG-WARN][34] ([fdo#110913 ])
> > >     [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-dsi/igt@gem_exec_fence@basic-busy-default.html
> > >     [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-dsi/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-bdw-5557u:       [PASS][35] -> [DMESG-WARN][36] ([fdo#110913 ])
> > >     [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bdw-5557u/igt@gem_exec_fence@basic-busy-default.html
> > >     [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bdw-5557u/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-kbl-7500u:       [PASS][37] -> [DMESG-WARN][38] ([fdo#110913 ])
> > >     [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7500u/igt@gem_exec_fence@basic-busy-default.html
> > >     [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7500u/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-kbl-8809g:       [PASS][39] -> [DMESG-WARN][40] ([fdo#110913 ])
> > >     [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-8809g/igt@gem_exec_fence@basic-busy-default.html
> > >     [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-8809g/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-bxt-dsi:         [PASS][41] -> [DMESG-WARN][42] ([fdo#109385] / [fdo#110913 ])
> > >     [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bxt-dsi/igt@gem_exec_fence@basic-busy-default.html
> > >     [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bxt-dsi/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-whl-u:           [PASS][43] -> [DMESG-WARN][44] ([fdo#110913 ])
> > >     [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-whl-u/igt@gem_exec_fence@basic-busy-default.html
> > >     [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-whl-u/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-skl-gvtdvm:      [PASS][45] -> [DMESG-WARN][46] ([fdo#110913 ])
> > >     [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
> > >     [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-cml-u:           [PASS][47] -> [DMESG-WARN][48] ([fdo#110913 ])
> > >     [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
> > >     [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-bsw-n3050:       [PASS][49] -> [DMESG-WARN][50] ([fdo#109385] / [fdo#110913 ])
> > >     [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bsw-n3050/igt@gem_exec_fence@basic-busy-default.html
> > >     [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bsw-n3050/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-ilk-650:         [PASS][51] -> [DMESG-WARN][52] ([fdo#110913 ])
> > >     [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-ilk-650/igt@gem_exec_fence@basic-busy-default.html
> > >     [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-ilk-650/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-hsw-4770:        [PASS][53] -> [DMESG-WARN][54] ([fdo#110913 ])
> > >     [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-hsw-4770/igt@gem_exec_fence@basic-busy-default.html
> > >     [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-hsw-4770/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-bdw-gvtdvm:      [PASS][55] -> [DMESG-WARN][56] ([fdo#110913 ])
> > >     [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bdw-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
> > >     [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bdw-gvtdvm/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-skl-iommu:       [PASS][57] -> [DMESG-WARN][58] ([fdo#110913 ])
> > >     [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-iommu/igt@gem_exec_fence@basic-busy-default.html
> > >     [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-iommu/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-kbl-7567u:       [PASS][59] -> [DMESG-WARN][60] ([fdo#110913 ])
> > >     [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7567u/igt@gem_exec_fence@basic-busy-default.html
> > >     [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7567u/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-ivb-3770:        [PASS][61] -> [DMESG-WARN][62] ([fdo#110913 ])
> > >     [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-ivb-3770/igt@gem_exec_fence@basic-busy-default.html
> > >     [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-ivb-3770/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-snb-2520m:       [PASS][63] -> [DMESG-WARN][64] ([fdo#110913 ])
> > >     [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-snb-2520m/igt@gem_exec_fence@basic-busy-default.html
> > >     [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-snb-2520m/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-kbl-guc:         [PASS][65] -> [DMESG-WARN][66] ([fdo#110913 ])
> > >     [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-guc/igt@gem_exec_fence@basic-busy-default.html
> > >     [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-guc/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-bsw-kefka:       [PASS][67] -> [DMESG-WARN][68] ([fdo#109385] / [fdo#110913 ])
> > >     [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bsw-kefka/igt@gem_exec_fence@basic-busy-default.html
> > >     [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bsw-kefka/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-kbl-r:           [PASS][69] -> [DMESG-WARN][70] ([fdo#110913 ])
> > >     [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-r/igt@gem_exec_fence@basic-busy-default.html
> > >     [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-r/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-skl-6770hq:      [PASS][71] -> [DMESG-WARN][72] ([fdo#110913 ])
> > >     [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6770hq/igt@gem_exec_fence@basic-busy-default.html
> > >     [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6770hq/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-byt-n2820:       [PASS][73] -> [DMESG-WARN][74] ([fdo#110913 ])
> > >     [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-byt-n2820/igt@gem_exec_fence@basic-busy-default.html
> > >     [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-byt-n2820/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-cfl-8109u:       [PASS][75] -> [DMESG-WARN][76] ([fdo#110913 ])
> > >     [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-cfl-8109u/igt@gem_exec_fence@basic-busy-default.html
> > >     [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cfl-8109u/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-icl-u3:          [PASS][77] -> [DMESG-WARN][78] ([fdo#110913 ])
> > >     [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_exec_fence@basic-busy-default.html
> > >     [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-byt-j1900:       [PASS][79] -> [DMESG-WARN][80] ([fdo#110913 ])
> > >     [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-byt-j1900/igt@gem_exec_fence@basic-busy-default.html
> > >     [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-byt-j1900/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-skl-6260u:       [PASS][81] -> [DMESG-WARN][82] ([fdo#110913 ])
> > >     [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6260u/igt@gem_exec_fence@basic-busy-default.html
> > >     [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6260u/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-bxt-j4205:       [PASS][83] -> [DMESG-WARN][84] ([fdo#109385] / [fdo#110913 ])
> > >     [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-bxt-j4205/igt@gem_exec_fence@basic-busy-default.html
> > >     [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-bxt-j4205/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-snb-2600:        [PASS][85] -> [DMESG-WARN][86] ([fdo#110913 ])
> > >     [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-snb-2600/igt@gem_exec_fence@basic-busy-default.html
> > >     [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-snb-2600/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-elk-e7500:       [PASS][87] -> [DMESG-WARN][88] ([fdo#110913 ])
> > >     [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-elk-e7500/igt@gem_exec_fence@basic-busy-default.html
> > >     [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-elk-e7500/igt@gem_exec_fence@basic-busy-default.html
> > >      - fi-skl-6700k2:      [PASS][89] -> [DMESG-WARN][90] ([fdo#110913 ])
> > >     [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-6700k2/igt@gem_exec_fence@basic-busy-default.html
> > >     [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-6700k2/igt@gem_exec_fence@basic-busy-default.html
> > > 
> > > #### Possible fixes ####
> > > 
> > >    * igt@gem_exec_fence@basic-wait-default:
> > >      - fi-icl-u3:          [DMESG-WARN][91] ([fdo#107724]) -> [PASS][92] +2 similar issues
> > >     [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_exec_fence@basic-wait-default.html
> > >     [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_exec_fence@basic-wait-default.html
> > > 
> > >    {name}: This element is suppressed. This means it is ignored when computing
> > >            the status of the difference (SUCCESS, WARNING, or FAILURE).
> > > 
> > >    [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
> > >    [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
> > >    [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
> > >    [fdo#109385]: https://bugs.freedesktop.org/show_bug.cgi?id=109385
> > >    [fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913
> > > 
> > > 
> > > Participating hosts (54 -> 46)
> > > ------------------------------
> > > 
> > >    Additional (1): fi-cml-u2
> > >    Missing    (9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus
> > > 
> > > 
> > > Build changes
> > > -------------
> > > 
> > >    * Linux: CI_DRM_6358 -> Patchwork_13438
> > > 
> > >    CI_DRM_6358: 3454454b146cd9f684feb07ab9dff61dc875a022 @ git://anongit.freedesktop.org/gfx-ci/linux
> > >    IGT_5068: 15ad664534413628f06c0f172aac11598bfdb895 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> > >    Patchwork_13438: fbf9925e3e0220296c42260729dff5cc9d5d4c84 @ git://anongit.freedesktop.org/gfx-ci/linux
> > > 
> > > 
> > > == Linux commits ==
> > > 
> > > fbf9925e3e02 drm/amdgpu: add independent DMA-buf import v7
> > > 13b9bef056c0 drm/amdgpu: add independent DMA-buf export v6
> > > b0d7a97cb362 drm/amdgpu: use allowed_domains for exported DMA-bufs
> > > 4624e4f46a05 drm/ttm: use the parent resv for ghost objects v2
> > > 8f8445fa6219 drm/ttm: remove the backing store if no placement is given
> > > 6d09a7de3969 dma-buf: add dynamic DMA-buf handling v13
> > > 
> > > == Logs ==
> > > 
> > > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

Re: ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Koenig, Christian]

Am 07.08.19 um 23:19 schrieb Daniel Vetter:
> On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
>> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
>>> Hi Daniel,
>>>
>>> those fails look like something random to me and not related to my patch
>>> set. Correct?
>> First one I looked at has the reservation_obj all over:
>>
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
>>
>> So 5 second guees is ... probably real?
>>
>> Note that with the entire lmem stuff going on right now there's massive
>> discussions about how we're doing resv_obj vs obj->mm.lock the wrong way
>> round in i915, so I'm not surprised at all that you managed to trip this.
>>
>> The way I see it right now is that obj->mm.lock needs to be limited to
>> dealing with the i915 shrinker interactions only, and only for i915 native
>> objects. And for dma-bufs we need to make sure it's not anywhere in the
>> callchain. Unfortunately that's a massive refactor I guess ...
> Thought about this some more, aside from just breaking i915 or waiting
> until it's refactored (Both not awesome) I think the only option is get
> back to the original caching. And figure out whether we really need to
> take the direction into account for that, or whether upgrading to
> bidirectional unconditionally won't be ok. I think there's only really two
> cases where this matters:
>
> - display drivers using the cma/dma_alloc helpers. Everything is allocated
>    fully coherent, cpu side wc, no flushing.
>
> - Everyone else (on platforms where there's actually some flushing going
>    on) is for rendering gpus, and those always map bidirectional and want
>    the mapping cached for as long as possible.
>
> With that we could go back to creating the cached mapping at attach time
> and avoid inflicting the reservation object lock to places that would keel
> over.
>
> Thoughts?

Actually we had a not so nice internal mail thread with our hardware 
guys and it looks like we have tons of hardware bugs/exceptions that 
sometimes PCIe BARs are only readable or only writable. So it turned out 
that always caching with bidirectional won't work for us either.

Additional to that I'm not sure how i915 actually triggered the issue, 
cause with the current code that shouldn't be possible.

But independent of that I came to the conclusion that we first need to 
get to a common view of what the fences in the reservation mean or 
otherwise the whole stuff here isn't going to work smooth either.

So working on that for now and when that's finished I will come back to 
this problem here again.

Regards,
Christian.


> -Daniel
>

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

Re: ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Daniel Vetter]

On Thu, Aug 8, 2019 at 9:09 AM Koenig, Christian
<Christian.Koenig@amd.com> wrote:
>
> Am 07.08.19 um 23:19 schrieb Daniel Vetter:
> > On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
> >> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> >>> Hi Daniel,
> >>>
> >>> those fails look like something random to me and not related to my patch
> >>> set. Correct?
> >> First one I looked at has the reservation_obj all over:
> >>
> >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
> >>
> >> So 5 second guees is ... probably real?
> >>
> >> Note that with the entire lmem stuff going on right now there's massive
> >> discussions about how we're doing resv_obj vs obj->mm.lock the wrong way
> >> round in i915, so I'm not surprised at all that you managed to trip this.
> >>
> >> The way I see it right now is that obj->mm.lock needs to be limited to
> >> dealing with the i915 shrinker interactions only, and only for i915 native
> >> objects. And for dma-bufs we need to make sure it's not anywhere in the
> >> callchain. Unfortunately that's a massive refactor I guess ...
> > Thought about this some more, aside from just breaking i915 or waiting
> > until it's refactored (Both not awesome) I think the only option is get
> > back to the original caching. And figure out whether we really need to
> > take the direction into account for that, or whether upgrading to
> > bidirectional unconditionally won't be ok. I think there's only really two
> > cases where this matters:
> >
> > - display drivers using the cma/dma_alloc helpers. Everything is allocated
> >    fully coherent, cpu side wc, no flushing.
> >
> > - Everyone else (on platforms where there's actually some flushing going
> >    on) is for rendering gpus, and those always map bidirectional and want
> >    the mapping cached for as long as possible.
> >
> > With that we could go back to creating the cached mapping at attach time
> > and avoid inflicting the reservation object lock to places that would keel
> > over.
> >
> > Thoughts?
>
> Actually we had a not so nice internal mail thread with our hardware
> guys and it looks like we have tons of hardware bugs/exceptions that
> sometimes PCIe BARs are only readable or only writable. So it turned out
> that always caching with bidirectional won't work for us either.
>
> Additional to that I'm not sure how i915 actually triggered the issue,
> cause with the current code that shouldn't be possible.
>
> But independent of that I came to the conclusion that we first need to
> get to a common view of what the fences in the reservation mean or
> otherwise the whole stuff here isn't going to work smooth either.
>
> So working on that for now and when that's finished I will come back to
> this problem here again.

Yeah makes sense. I think we also need to clarify a bit the existing
rules around reservatrion_object, dma_fence signaling, and how that
nests with everything else (like memory allocation/fs_reclaim critical
sections, or mmap_sem).

Ignore the drivers which just pin everything system memory (mostly
just socs) I think we have a bunch of groups, and they're all somewhat
incompatible with each another. Examples:

- old ttm drivers (anything except amdgpu) nest the mmap_sem within
the reservation_object. That allows you to do copy_*_user while
holding reservations, simplifying command submission since you don't
need fallback paths when you take a fault. But means you have this
awkward trylock in the mmap path with no forward progress guarantee at
all.

amdgpu fixed that (but left ttm alone), i915 also works like that with
mmap_sem being the outer lock.

- other is reservation_object vs memory allocations. Currently all
drivers assume you can allocate memory while holding a reservation,
but i915 gem folks seem to have some plans to change that for i915.
Which isn't going to work I think, so we need to clarify that before
things get more inconsistent.

Above two can at least be ensured by adding somme lockdep annotations
and dependency priming, see i915_gem_shrinker_taints_mutex for what I
have in mind for reservation_obj.

The real pain/scary thing is dma_fence. All the
shrinkers/mmu_notifiers/hmm_mirrors we have assume that you can wait
for a fence from allocation contexts/direct reclaim. Which means
nothing you do between publishing a fence somewhere (dma-buf, syncobj,
syncpt fd) and signalling that fence is allowed to allocate memory or
pull in any dependencies which might need memory allocations. I think
we're mostly ok with this, but there's some i915 patches that break
this.

Much worse is that lockdep can't help us check this: dma_fence is
essentially struct completion on steroids, and the cross-release
lockdep support for struct completion looks like it's never going to
get merged. So no debugging aids to make sure we get this right, all
we have is review and testing and machines deadlocking in really
complicated ways if we get it wrong.

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: ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Daniel Vetter]

On Thu, Aug 8, 2019 at 9:09 AM Koenig, Christian
<Christian.Koenig@amd.com> wrote:
>
> Am 07.08.19 um 23:19 schrieb Daniel Vetter:
> > On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
> >> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> >>> Hi Daniel,
> >>>
> >>> those fails look like something random to me and not related to my patch
> >>> set. Correct?
> >> First one I looked at has the reservation_obj all over:
> >>
> >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
> >>
> >> So 5 second guees is ... probably real?
> >>
> >> Note that with the entire lmem stuff going on right now there's massive
> >> discussions about how we're doing resv_obj vs obj->mm.lock the wrong way
> >> round in i915, so I'm not surprised at all that you managed to trip this.
> >>
> >> The way I see it right now is that obj->mm.lock needs to be limited to
> >> dealing with the i915 shrinker interactions only, and only for i915 native
> >> objects. And for dma-bufs we need to make sure it's not anywhere in the
> >> callchain. Unfortunately that's a massive refactor I guess ...
> > Thought about this some more, aside from just breaking i915 or waiting
> > until it's refactored (Both not awesome) I think the only option is get
> > back to the original caching. And figure out whether we really need to
> > take the direction into account for that, or whether upgrading to
> > bidirectional unconditionally won't be ok. I think there's only really two
> > cases where this matters:
> >
> > - display drivers using the cma/dma_alloc helpers. Everything is allocated
> >    fully coherent, cpu side wc, no flushing.
> >
> > - Everyone else (on platforms where there's actually some flushing going
> >    on) is for rendering gpus, and those always map bidirectional and want
> >    the mapping cached for as long as possible.
> >
> > With that we could go back to creating the cached mapping at attach time
> > and avoid inflicting the reservation object lock to places that would keel
> > over.
> >
> > Thoughts?
>
> Actually we had a not so nice internal mail thread with our hardware
> guys and it looks like we have tons of hardware bugs/exceptions that
> sometimes PCIe BARs are only readable or only writable. So it turned out
> that always caching with bidirectional won't work for us either.
>
> Additional to that I'm not sure how i915 actually triggered the issue,
> cause with the current code that shouldn't be possible.

Forgot to explain this: i915 has it's own lock for managing buffer
state, originally struct_mutex, now also i915_gem_obj->mm.lock. When
importing we take both of these before calling into the exporter, when
exporting we need these when getting called from the import. If the
importer uses the reservation_object lock you get a classic ABBA
deadlock.

I thought the plan was to push struct_mutex down and obj->mm.lock up
until they meet in the middle and we can start using the resv_obj
ww_mutex for everything. But looking at some of the latest in-flight
patches (I cc'ed you on them) that seems to not really be the plan,
which is bad :-/
-Daniel

> But independent of that I came to the conclusion that we first need to
> get to a common view of what the fences in the reservation mean or
> otherwise the whole stuff here isn't going to work smooth either.
>
> So working on that for now and when that's finished I will come back to
> this problem here again.
>
> Regards,
> Christian.
>
>
> > -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: ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Koenig, Christian]

Am 08.08.19 um 09:29 schrieb Daniel Vetter:
> On Thu, Aug 8, 2019 at 9:09 AM Koenig, Christian
> <Christian.Koenig@amd.com> wrote:
>> Am 07.08.19 um 23:19 schrieb Daniel Vetter:
>>> On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
>>>> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> those fails look like something random to me and not related to my patch
>>>>> set. Correct?
>>>> First one I looked at has the reservation_obj all over:
>>>>
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
>>>>
>>>> So 5 second guees is ... probably real?
>>>>
>>>> Note that with the entire lmem stuff going on right now there's massive
>>>> discussions about how we're doing resv_obj vs obj->mm.lock the wrong way
>>>> round in i915, so I'm not surprised at all that you managed to trip this.
>>>>
>>>> The way I see it right now is that obj->mm.lock needs to be limited to
>>>> dealing with the i915 shrinker interactions only, and only for i915 native
>>>> objects. And for dma-bufs we need to make sure it's not anywhere in the
>>>> callchain. Unfortunately that's a massive refactor I guess ...
>>> Thought about this some more, aside from just breaking i915 or waiting
>>> until it's refactored (Both not awesome) I think the only option is get
>>> back to the original caching. And figure out whether we really need to
>>> take the direction into account for that, or whether upgrading to
>>> bidirectional unconditionally won't be ok. I think there's only really two
>>> cases where this matters:
>>>
>>> - display drivers using the cma/dma_alloc helpers. Everything is allocated
>>>     fully coherent, cpu side wc, no flushing.
>>>
>>> - Everyone else (on platforms where there's actually some flushing going
>>>     on) is for rendering gpus, and those always map bidirectional and want
>>>     the mapping cached for as long as possible.
>>>
>>> With that we could go back to creating the cached mapping at attach time
>>> and avoid inflicting the reservation object lock to places that would keel
>>> over.
>>>
>>> Thoughts?
>> Actually we had a not so nice internal mail thread with our hardware
>> guys and it looks like we have tons of hardware bugs/exceptions that
>> sometimes PCIe BARs are only readable or only writable. So it turned out
>> that always caching with bidirectional won't work for us either.
>>
>> Additional to that I'm not sure how i915 actually triggered the issue,
>> cause with the current code that shouldn't be possible.
>>
>> But independent of that I came to the conclusion that we first need to
>> get to a common view of what the fences in the reservation mean or
>> otherwise the whole stuff here isn't going to work smooth either.
>>
>> So working on that for now and when that's finished I will come back to
>> this problem here again.
> Yeah makes sense. I think we also need to clarify a bit the existing
> rules around reservatrion_object, dma_fence signaling, and how that
> nests with everything else (like memory allocation/fs_reclaim critical
> sections, or mmap_sem).
>
> Ignore the drivers which just pin everything system memory (mostly
> just socs) I think we have a bunch of groups, and they're all somewhat
> incompatible with each another. Examples:
>
> - old ttm drivers (anything except amdgpu) nest the mmap_sem within
> the reservation_object. That allows you to do copy_*_user while
> holding reservations, simplifying command submission since you don't
> need fallback paths when you take a fault. But means you have this
> awkward trylock in the mmap path with no forward progress guarantee at
> all.
>
> amdgpu fixed that (but left ttm alone), i915 also works like that with
> mmap_sem being the outer lock.

By the way that is incorrect. Both amdgpu as well as readeon don't use 
copy_to/from_user while holding the reservation lock.

The last time I checked the only driver still doing that was nouveau.

Maybe time to add a might_lock() so that we will be informed about 
misuse by lockdep?

Christian.

>
> - other is reservation_object vs memory allocations. Currently all
> drivers assume you can allocate memory while holding a reservation,
> but i915 gem folks seem to have some plans to change that for i915.
> Which isn't going to work I think, so we need to clarify that before
> things get more inconsistent.
>
> Above two can at least be ensured by adding somme lockdep annotations
> and dependency priming, see i915_gem_shrinker_taints_mutex for what I
> have in mind for reservation_obj.
>
> The real pain/scary thing is dma_fence. All the
> shrinkers/mmu_notifiers/hmm_mirrors we have assume that you can wait
> for a fence from allocation contexts/direct reclaim. Which means
> nothing you do between publishing a fence somewhere (dma-buf, syncobj,
> syncpt fd) and signalling that fence is allowed to allocate memory or
> pull in any dependencies which might need memory allocations. I think
> we're mostly ok with this, but there's some i915 patches that break
> this.
>
> Much worse is that lockdep can't help us check this: dma_fence is
> essentially struct completion on steroids, and the cross-release
> lockdep support for struct completion looks like it's never going to
> get merged. So no debugging aids to make sure we get this right, all
> we have is review and testing and machines deadlocking in really
> complicated ways if we get it wrong.
>
> Cheers, Daniel

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

Re: ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13

[Daniel Vetter]

On Thu, Aug 8, 2019 at 1:05 PM Koenig, Christian
<Christian.Koenig@amd.com> wrote:
> Am 08.08.19 um 09:29 schrieb Daniel Vetter:
> > On Thu, Aug 8, 2019 at 9:09 AM Koenig, Christian
> > <Christian.Koenig@amd.com> wrote:
> >> Am 07.08.19 um 23:19 schrieb Daniel Vetter:
> >>> On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote:
> >>>> On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote:
> >>>>> Hi Daniel,
> >>>>>
> >>>>> those fails look like something random to me and not related to my patch
> >>>>> set. Correct?
> >>>> First one I looked at has the reservation_obj all over:
> >>>>
> >>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fence@basic-busy-default.html
> >>>>
> >>>> So 5 second guees is ... probably real?
> >>>>
> >>>> Note that with the entire lmem stuff going on right now there's massive
> >>>> discussions about how we're doing resv_obj vs obj->mm.lock the wrong way
> >>>> round in i915, so I'm not surprised at all that you managed to trip this.
> >>>>
> >>>> The way I see it right now is that obj->mm.lock needs to be limited to
> >>>> dealing with the i915 shrinker interactions only, and only for i915 native
> >>>> objects. And for dma-bufs we need to make sure it's not anywhere in the
> >>>> callchain. Unfortunately that's a massive refactor I guess ...
> >>> Thought about this some more, aside from just breaking i915 or waiting
> >>> until it's refactored (Both not awesome) I think the only option is get
> >>> back to the original caching. And figure out whether we really need to
> >>> take the direction into account for that, or whether upgrading to
> >>> bidirectional unconditionally won't be ok. I think there's only really two
> >>> cases where this matters:
> >>>
> >>> - display drivers using the cma/dma_alloc helpers. Everything is allocated
> >>>     fully coherent, cpu side wc, no flushing.
> >>>
> >>> - Everyone else (on platforms where there's actually some flushing going
> >>>     on) is for rendering gpus, and those always map bidirectional and want
> >>>     the mapping cached for as long as possible.
> >>>
> >>> With that we could go back to creating the cached mapping at attach time
> >>> and avoid inflicting the reservation object lock to places that would keel
> >>> over.
> >>>
> >>> Thoughts?
> >> Actually we had a not so nice internal mail thread with our hardware
> >> guys and it looks like we have tons of hardware bugs/exceptions that
> >> sometimes PCIe BARs are only readable or only writable. So it turned out
> >> that always caching with bidirectional won't work for us either.
> >>
> >> Additional to that I'm not sure how i915 actually triggered the issue,
> >> cause with the current code that shouldn't be possible.
> >>
> >> But independent of that I came to the conclusion that we first need to
> >> get to a common view of what the fences in the reservation mean or
> >> otherwise the whole stuff here isn't going to work smooth either.
> >>
> >> So working on that for now and when that's finished I will come back to
> >> this problem here again.
> > Yeah makes sense. I think we also need to clarify a bit the existing
> > rules around reservatrion_object, dma_fence signaling, and how that
> > nests with everything else (like memory allocation/fs_reclaim critical
> > sections, or mmap_sem).
> >
> > Ignore the drivers which just pin everything system memory (mostly
> > just socs) I think we have a bunch of groups, and they're all somewhat
> > incompatible with each another. Examples:
> >
> > - old ttm drivers (anything except amdgpu) nest the mmap_sem within
> > the reservation_object. That allows you to do copy_*_user while
> > holding reservations, simplifying command submission since you don't
> > need fallback paths when you take a fault. But means you have this
> > awkward trylock in the mmap path with no forward progress guarantee at
> > all.
> >
> > amdgpu fixed that (but left ttm alone), i915 also works like that with
> > mmap_sem being the outer lock.
>
> By the way that is incorrect. Both amdgpu as well as readeon don't use
> copy_to/from_user while holding the reservation lock.

Cool, this is great. When I recently re-read a pile of code in there I
only looked at the amdgpu cs again in detail. And yeah on rechecking
at least nouveau does it backwards still, first it calls
nouveau_gem_pushbuf_validate (which does all the ww_mutex stuff), then
nouveau_gem_pushbuf_reloc_apply (which calls copy_from_user and
doesn't seem to have any fallback/retry or slowpath that does the copy
without holding).

I think vmwgfx is also (no longer?) inverted, it seems to drop the
resv_obj locks in  vmw_validation_bo_fence(), and only after that call
vmw_execbuf_copy_fence_user(). So not a resv_obj vs. mmap_sem
inversion, but the copy_*_user might trigger the shrinker. At least
amdgpu and i915 rely on being able to wait on published fences in
there, so we might look at some other inversion here. Unfortunately
this isn't one lockdep can catch :-/

> The last time I checked the only driver still doing that was nouveau.
>
> Maybe time to add a might_lock() so that we will be informed about
> misuse by lockdep?

Not even a might_lock, just priming the lockdep dependency tracking by
essentially doing a quick sequence of:

mutex_lock(mmap_sem);
reservation_object_lock();
fs_reclaim_acquire(GFP_KERNEL);

And then unwinding. Once you've done that then lockdep will know that
a) resv_obj nests within mmap_sem
b) you can allocate memory when holding a resv_obj

And like with any other lockdep splats it will loudly complain if
anyone breaks the rules. Since we know that nouveau (and probably also
vmwgfx I guess) breaks the rules we'll probably need to hide this
behind CONFIG_DEBUG_WW_MUTEX_SLOWPATH or something similar.

I'm also working on some lockdep annotation improvements for
mmu_notifier. We might also want to make sure we handle that part
consistent across drivers, but I'm much less clear on what the real
rules are there (aside from i915 userptr looks really strange compared
to the amdgpu one).
-Daniel

>
> Christian.
>
> >
> > - other is reservation_object vs memory allocations. Currently all
> > drivers assume you can allocate memory while holding a reservation,
> > but i915 gem folks seem to have some plans to change that for i915.
> > Which isn't going to work I think, so we need to clarify that before
> > things get more inconsistent.
> >
> > Above two can at least be ensured by adding somme lockdep annotations
> > and dependency priming, see i915_gem_shrinker_taints_mutex for what I
> > have in mind for reservation_obj.
> >
> > The real pain/scary thing is dma_fence. All the
> > shrinkers/mmu_notifiers/hmm_mirrors we have assume that you can wait
> > for a fence from allocation contexts/direct reclaim. Which means
> > nothing you do between publishing a fence somewhere (dma-buf, syncobj,
> > syncpt fd) and signalling that fence is allowed to allocate memory or
> > pull in any dependencies which might need memory allocations. I think
> > we're mostly ok with this, but there's some i915 patches that break
> > this.
> >
> > Much worse is that lockdep can't help us check this: dma_fence is
> > essentially struct completion on steroids, and the cross-release
> > lockdep support for struct completion looks like it's never going to
> > get merged. So no debugging aids to make sure we get this right, all
> > we have is review and testing and machines deadlocking in really
> > complicated ways if we get it wrong.
> >
> > 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