* [PATCH v2 1/4] dma-buf: Rename .move_notify() callback to a clearer identifier
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
@ 2026-01-18 12:08 ` Leon Romanovsky
2026-01-19 10:22 ` Christian König
2026-01-18 12:08 ` [PATCH v2 2/4] dma-buf: Document revoke semantics Leon Romanovsky
` (8 subsequent siblings)
9 siblings, 1 reply; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-18 12:08 UTC (permalink / raw)
To: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Leon Romanovsky, Kevin Tian, Joerg Roedel,
Will Deacon, Robin Murphy, Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
From: Leon Romanovsky <leonro@nvidia.com>
Rename the .move_notify() callback to .invalidate_mappings() to make its
purpose explicit and highlight that it is responsible for invalidating
existing mappings.
Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/dma-buf/dma-buf.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
drivers/infiniband/core/umem_dmabuf.c | 4 ++--
drivers/infiniband/hw/mlx5/mr.c | 2 +-
drivers/iommu/iommufd/pages.c | 2 +-
include/linux/dma-buf.h | 6 +++---
9 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index edaa9e4ee4ae..59cc647bf40e 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -948,7 +948,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
if (WARN_ON(!dmabuf || !dev))
return ERR_PTR(-EINVAL);
- if (WARN_ON(importer_ops && !importer_ops->move_notify))
+ if (WARN_ON(importer_ops && !importer_ops->invalidate_mappings))
return ERR_PTR(-EINVAL);
attach = kzalloc(sizeof(*attach), GFP_KERNEL);
@@ -1055,7 +1055,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_pin, "DMA_BUF");
*
* This unpins a buffer pinned by dma_buf_pin() and allows the exporter to move
* any mapping of @attach again and inform the importer through
- * &dma_buf_attach_ops.move_notify.
+ * &dma_buf_attach_ops.invalidate_mappings.
*/
void dma_buf_unpin(struct dma_buf_attachment *attach)
{
@@ -1262,7 +1262,7 @@ void dma_buf_move_notify(struct dma_buf *dmabuf)
list_for_each_entry(attach, &dmabuf->attachments, node)
if (attach->importer_ops)
- attach->importer_ops->move_notify(attach);
+ attach->importer_ops->invalidate_mappings(attach);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, "DMA_BUF");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e22cfa7c6d32..863454148b28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -450,7 +450,7 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
}
/**
- * amdgpu_dma_buf_move_notify - &attach.move_notify implementation
+ * amdgpu_dma_buf_move_notify - &attach.invalidate_mappings implementation
*
* @attach: the DMA-buf attachment
*
@@ -521,7 +521,7 @@ amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
.allow_peer2peer = true,
- .move_notify = amdgpu_dma_buf_move_notify
+ .invalidate_mappings = amdgpu_dma_buf_move_notify
};
/**
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c
index ce49282198cb..19c78dd2ca77 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -288,7 +288,7 @@ static void virtgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
static const struct dma_buf_attach_ops virtgpu_dma_buf_attach_ops = {
.allow_peer2peer = true,
- .move_notify = virtgpu_dma_buf_move_notify
+ .invalidate_mappings = virtgpu_dma_buf_move_notify
};
struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev,
diff --git a/drivers/gpu/drm/xe/tests/xe_dma_buf.c b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
index 5df98de5ba3c..1f2cca5c2f81 100644
--- a/drivers/gpu/drm/xe/tests/xe_dma_buf.c
+++ b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
@@ -23,7 +23,7 @@ static bool p2p_enabled(struct dma_buf_test_params *params)
static bool is_dynamic(struct dma_buf_test_params *params)
{
return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) && params->attach_ops &&
- params->attach_ops->move_notify;
+ params->attach_ops->invalidate_mappings;
}
static void check_residency(struct kunit *test, struct xe_bo *exported,
@@ -60,7 +60,7 @@ static void check_residency(struct kunit *test, struct xe_bo *exported,
/*
* Evict exporter. Evicting the exported bo will
- * evict also the imported bo through the move_notify() functionality if
+ * evict also the imported bo through the invalidate_mappings() functionality if
* importer is on a different device. If they're on the same device,
* the exporter and the importer should be the same bo.
*/
@@ -198,7 +198,7 @@ static void xe_test_dmabuf_import_same_driver(struct xe_device *xe)
static const struct dma_buf_attach_ops nop2p_attach_ops = {
.allow_peer2peer = false,
- .move_notify = xe_dma_buf_move_notify
+ .invalidate_mappings = xe_dma_buf_move_notify
};
/*
diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
index 7c74a31d4486..1b9cd043e517 100644
--- a/drivers/gpu/drm/xe/xe_dma_buf.c
+++ b/drivers/gpu/drm/xe/xe_dma_buf.c
@@ -287,7 +287,7 @@ static void xe_dma_buf_move_notify(struct dma_buf_attachment *attach)
static const struct dma_buf_attach_ops xe_dma_buf_attach_ops = {
.allow_peer2peer = true,
- .move_notify = xe_dma_buf_move_notify
+ .invalidate_mappings = xe_dma_buf_move_notify
};
#if IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST)
diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c
index 0ec2e4120cc9..d77a739cfe7a 100644
--- a/drivers/infiniband/core/umem_dmabuf.c
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -129,7 +129,7 @@ ib_umem_dmabuf_get_with_dma_device(struct ib_device *device,
if (check_add_overflow(offset, (unsigned long)size, &end))
return ret;
- if (unlikely(!ops || !ops->move_notify))
+ if (unlikely(!ops || !ops->invalidate_mappings))
return ret;
dmabuf = dma_buf_get(fd);
@@ -195,7 +195,7 @@ ib_umem_dmabuf_unsupported_move_notify(struct dma_buf_attachment *attach)
static struct dma_buf_attach_ops ib_umem_dmabuf_attach_pinned_ops = {
.allow_peer2peer = true,
- .move_notify = ib_umem_dmabuf_unsupported_move_notify,
+ .invalidate_mappings = ib_umem_dmabuf_unsupported_move_notify,
};
struct ib_umem_dmabuf *
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 325fa04cbe8a..97099d3b1688 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1620,7 +1620,7 @@ static void mlx5_ib_dmabuf_invalidate_cb(struct dma_buf_attachment *attach)
static struct dma_buf_attach_ops mlx5_ib_dmabuf_attach_ops = {
.allow_peer2peer = 1,
- .move_notify = mlx5_ib_dmabuf_invalidate_cb,
+ .invalidate_mappings = mlx5_ib_dmabuf_invalidate_cb,
};
static struct ib_mr *
diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c
index dbe51ecb9a20..76f900fa1687 100644
--- a/drivers/iommu/iommufd/pages.c
+++ b/drivers/iommu/iommufd/pages.c
@@ -1451,7 +1451,7 @@ static void iopt_revoke_notify(struct dma_buf_attachment *attach)
static struct dma_buf_attach_ops iopt_dmabuf_attach_revoke_ops = {
.allow_peer2peer = true,
- .move_notify = iopt_revoke_notify,
+ .invalidate_mappings = iopt_revoke_notify,
};
/*
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 0bc492090237..1b397635c793 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -407,7 +407,7 @@ struct dma_buf {
* through the device.
*
* - Dynamic importers should set fences for any access that they can't
- * disable immediately from their &dma_buf_attach_ops.move_notify
+ * disable immediately from their &dma_buf_attach_ops.invalidate_mappings
* callback.
*
* IMPORTANT:
@@ -458,7 +458,7 @@ struct dma_buf_attach_ops {
bool allow_peer2peer;
/**
- * @move_notify: [optional] notification that the DMA-buf is moving
+ * @invalidate_mappings: [optional] notification that the DMA-buf is moving
*
* If this callback is provided the framework can avoid pinning the
* backing store while mappings exists.
@@ -475,7 +475,7 @@ struct dma_buf_attach_ops {
* 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);
+ void (*invalidate_mappings)(struct dma_buf_attachment *attach);
};
/**
--
2.52.0
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v2 1/4] dma-buf: Rename .move_notify() callback to a clearer identifier
2026-01-18 12:08 ` [PATCH v2 1/4] dma-buf: Rename .move_notify() callback to a clearer identifier Leon Romanovsky
@ 2026-01-19 10:22 ` Christian König
2026-01-19 11:38 ` Leon Romanovsky
0 siblings, 1 reply; 37+ messages in thread
From: Christian König @ 2026-01-19 10:22 UTC (permalink / raw)
To: Leon Romanovsky, Sumit Semwal, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On 1/18/26 13:08, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> Rename the .move_notify() callback to .invalidate_mappings() to make its
> purpose explicit and highlight that it is responsible for invalidating
> existing mappings.
>
> Suggested-by: Christian König <christian.koenig@amd.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/dma-buf/dma-buf.c | 6 +++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
> drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
> drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
> drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
> drivers/infiniband/core/umem_dmabuf.c | 4 ++--
> drivers/infiniband/hw/mlx5/mr.c | 2 +-
> drivers/iommu/iommufd/pages.c | 2 +-
> include/linux/dma-buf.h | 6 +++---
> 9 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index edaa9e4ee4ae..59cc647bf40e 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -948,7 +948,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> if (WARN_ON(!dmabuf || !dev))
> return ERR_PTR(-EINVAL);
>
> - if (WARN_ON(importer_ops && !importer_ops->move_notify))
> + if (WARN_ON(importer_ops && !importer_ops->invalidate_mappings))
> return ERR_PTR(-EINVAL);
>
> attach = kzalloc(sizeof(*attach), GFP_KERNEL);
> @@ -1055,7 +1055,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_pin, "DMA_BUF");
> *
> * This unpins a buffer pinned by dma_buf_pin() and allows the exporter to move
> * any mapping of @attach again and inform the importer through
> - * &dma_buf_attach_ops.move_notify.
> + * &dma_buf_attach_ops.invalidate_mappings.
> */
> void dma_buf_unpin(struct dma_buf_attachment *attach)
> {
> @@ -1262,7 +1262,7 @@ void dma_buf_move_notify(struct dma_buf *dmabuf)
>
> list_for_each_entry(attach, &dmabuf->attachments, node)
> if (attach->importer_ops)
> - attach->importer_ops->move_notify(attach);
> + attach->importer_ops->invalidate_mappings(attach);
> }
> EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, "DMA_BUF");
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index e22cfa7c6d32..863454148b28 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -450,7 +450,7 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
> }
>
> /**
> - * amdgpu_dma_buf_move_notify - &attach.move_notify implementation
> + * amdgpu_dma_buf_move_notify - &attach.invalidate_mappings implementation
> *
> * @attach: the DMA-buf attachment
> *
> @@ -521,7 +521,7 @@ amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
>
> static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
> .allow_peer2peer = true,
> - .move_notify = amdgpu_dma_buf_move_notify
> + .invalidate_mappings = amdgpu_dma_buf_move_notify
> };
>
> /**
> diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c
> index ce49282198cb..19c78dd2ca77 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> @@ -288,7 +288,7 @@ static void virtgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
>
> static const struct dma_buf_attach_ops virtgpu_dma_buf_attach_ops = {
> .allow_peer2peer = true,
> - .move_notify = virtgpu_dma_buf_move_notify
> + .invalidate_mappings = virtgpu_dma_buf_move_notify
> };
>
> struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/xe/tests/xe_dma_buf.c b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> index 5df98de5ba3c..1f2cca5c2f81 100644
> --- a/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> @@ -23,7 +23,7 @@ static bool p2p_enabled(struct dma_buf_test_params *params)
> static bool is_dynamic(struct dma_buf_test_params *params)
> {
> return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) && params->attach_ops &&
> - params->attach_ops->move_notify;
> + params->attach_ops->invalidate_mappings;
> }
>
> static void check_residency(struct kunit *test, struct xe_bo *exported,
> @@ -60,7 +60,7 @@ static void check_residency(struct kunit *test, struct xe_bo *exported,
>
> /*
> * Evict exporter. Evicting the exported bo will
> - * evict also the imported bo through the move_notify() functionality if
> + * evict also the imported bo through the invalidate_mappings() functionality if
> * importer is on a different device. If they're on the same device,
> * the exporter and the importer should be the same bo.
> */
> @@ -198,7 +198,7 @@ static void xe_test_dmabuf_import_same_driver(struct xe_device *xe)
>
> static const struct dma_buf_attach_ops nop2p_attach_ops = {
> .allow_peer2peer = false,
> - .move_notify = xe_dma_buf_move_notify
> + .invalidate_mappings = xe_dma_buf_move_notify
> };
>
> /*
> diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
> index 7c74a31d4486..1b9cd043e517 100644
> --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> @@ -287,7 +287,7 @@ static void xe_dma_buf_move_notify(struct dma_buf_attachment *attach)
>
> static const struct dma_buf_attach_ops xe_dma_buf_attach_ops = {
> .allow_peer2peer = true,
> - .move_notify = xe_dma_buf_move_notify
> + .invalidate_mappings = xe_dma_buf_move_notify
> };
>
> #if IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST)
> diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c
> index 0ec2e4120cc9..d77a739cfe7a 100644
> --- a/drivers/infiniband/core/umem_dmabuf.c
> +++ b/drivers/infiniband/core/umem_dmabuf.c
> @@ -129,7 +129,7 @@ ib_umem_dmabuf_get_with_dma_device(struct ib_device *device,
> if (check_add_overflow(offset, (unsigned long)size, &end))
> return ret;
>
> - if (unlikely(!ops || !ops->move_notify))
> + if (unlikely(!ops || !ops->invalidate_mappings))
> return ret;
>
> dmabuf = dma_buf_get(fd);
> @@ -195,7 +195,7 @@ ib_umem_dmabuf_unsupported_move_notify(struct dma_buf_attachment *attach)
>
> static struct dma_buf_attach_ops ib_umem_dmabuf_attach_pinned_ops = {
> .allow_peer2peer = true,
> - .move_notify = ib_umem_dmabuf_unsupported_move_notify,
> + .invalidate_mappings = ib_umem_dmabuf_unsupported_move_notify,
> };
>
> struct ib_umem_dmabuf *
> diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
> index 325fa04cbe8a..97099d3b1688 100644
> --- a/drivers/infiniband/hw/mlx5/mr.c
> +++ b/drivers/infiniband/hw/mlx5/mr.c
> @@ -1620,7 +1620,7 @@ static void mlx5_ib_dmabuf_invalidate_cb(struct dma_buf_attachment *attach)
>
> static struct dma_buf_attach_ops mlx5_ib_dmabuf_attach_ops = {
> .allow_peer2peer = 1,
> - .move_notify = mlx5_ib_dmabuf_invalidate_cb,
> + .invalidate_mappings = mlx5_ib_dmabuf_invalidate_cb,
> };
>
> static struct ib_mr *
> diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c
> index dbe51ecb9a20..76f900fa1687 100644
> --- a/drivers/iommu/iommufd/pages.c
> +++ b/drivers/iommu/iommufd/pages.c
> @@ -1451,7 +1451,7 @@ static void iopt_revoke_notify(struct dma_buf_attachment *attach)
>
> static struct dma_buf_attach_ops iopt_dmabuf_attach_revoke_ops = {
> .allow_peer2peer = true,
> - .move_notify = iopt_revoke_notify,
> + .invalidate_mappings = iopt_revoke_notify,
> };
>
> /*
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 0bc492090237..1b397635c793 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -407,7 +407,7 @@ struct dma_buf {
> * through the device.
> *
> * - Dynamic importers should set fences for any access that they can't
> - * disable immediately from their &dma_buf_attach_ops.move_notify
> + * disable immediately from their &dma_buf_attach_ops.invalidate_mappings
> * callback.
> *
> * IMPORTANT:
> @@ -458,7 +458,7 @@ struct dma_buf_attach_ops {
> bool allow_peer2peer;
>
> /**
> - * @move_notify: [optional] notification that the DMA-buf is moving
> + * @invalidate_mappings: [optional] notification that the DMA-buf is moving
> *
> * If this callback is provided the framework can avoid pinning the
> * backing store while mappings exists.
> @@ -475,7 +475,7 @@ struct dma_buf_attach_ops {
> * 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);
> + void (*invalidate_mappings)(struct dma_buf_attachment *attach);
> };
>
> /**
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 1/4] dma-buf: Rename .move_notify() callback to a clearer identifier
2026-01-19 10:22 ` Christian König
@ 2026-01-19 11:38 ` Leon Romanovsky
2026-01-19 12:00 ` Christian König
0 siblings, 1 reply; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 11:38 UTC (permalink / raw)
To: Christian König
Cc: Sumit Semwal, Alex Deucher, David Airlie, Simona Vetter,
Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh, Chia-I Wu,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, amd-gfx, virtualization, intel-xe,
linux-rdma, iommu, kvm
On Mon, Jan 19, 2026 at 11:22:27AM +0100, Christian König wrote:
> On 1/18/26 13:08, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > Rename the .move_notify() callback to .invalidate_mappings() to make its
> > purpose explicit and highlight that it is responsible for invalidating
> > existing mappings.
> >
> > Suggested-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
>
> Reviewed-by: Christian König <christian.koenig@amd.com>
Thanks,
BTW, I didn't update the various xxx_move_notify() functions to use
xxx_invalidate_mappings() names. Should those be converted as well?
>
> > ---
> > drivers/dma-buf/dma-buf.c | 6 +++---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
> > drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
> > drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
> > drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
> > drivers/infiniband/core/umem_dmabuf.c | 4 ++--
> > drivers/infiniband/hw/mlx5/mr.c | 2 +-
> > drivers/iommu/iommufd/pages.c | 2 +-
> > include/linux/dma-buf.h | 6 +++---
> > 9 files changed, 17 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index edaa9e4ee4ae..59cc647bf40e 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -948,7 +948,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> > if (WARN_ON(!dmabuf || !dev))
> > return ERR_PTR(-EINVAL);
> >
> > - if (WARN_ON(importer_ops && !importer_ops->move_notify))
> > + if (WARN_ON(importer_ops && !importer_ops->invalidate_mappings))
> > return ERR_PTR(-EINVAL);
> >
> > attach = kzalloc(sizeof(*attach), GFP_KERNEL);
> > @@ -1055,7 +1055,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_pin, "DMA_BUF");
> > *
> > * This unpins a buffer pinned by dma_buf_pin() and allows the exporter to move
> > * any mapping of @attach again and inform the importer through
> > - * &dma_buf_attach_ops.move_notify.
> > + * &dma_buf_attach_ops.invalidate_mappings.
> > */
> > void dma_buf_unpin(struct dma_buf_attachment *attach)
> > {
> > @@ -1262,7 +1262,7 @@ void dma_buf_move_notify(struct dma_buf *dmabuf)
> >
> > list_for_each_entry(attach, &dmabuf->attachments, node)
> > if (attach->importer_ops)
> > - attach->importer_ops->move_notify(attach);
> > + attach->importer_ops->invalidate_mappings(attach);
> > }
> > EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, "DMA_BUF");
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > index e22cfa7c6d32..863454148b28 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > @@ -450,7 +450,7 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
> > }
> >
> > /**
> > - * amdgpu_dma_buf_move_notify - &attach.move_notify implementation
> > + * amdgpu_dma_buf_move_notify - &attach.invalidate_mappings implementation
> > *
> > * @attach: the DMA-buf attachment
> > *
> > @@ -521,7 +521,7 @@ amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
> >
> > static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
> > .allow_peer2peer = true,
> > - .move_notify = amdgpu_dma_buf_move_notify
> > + .invalidate_mappings = amdgpu_dma_buf_move_notify
> > };
> >
> > /**
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c
> > index ce49282198cb..19c78dd2ca77 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> > @@ -288,7 +288,7 @@ static void virtgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
> >
> > static const struct dma_buf_attach_ops virtgpu_dma_buf_attach_ops = {
> > .allow_peer2peer = true,
> > - .move_notify = virtgpu_dma_buf_move_notify
> > + .invalidate_mappings = virtgpu_dma_buf_move_notify
> > };
> >
> > struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev,
> > diff --git a/drivers/gpu/drm/xe/tests/xe_dma_buf.c b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> > index 5df98de5ba3c..1f2cca5c2f81 100644
> > --- a/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> > +++ b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> > @@ -23,7 +23,7 @@ static bool p2p_enabled(struct dma_buf_test_params *params)
> > static bool is_dynamic(struct dma_buf_test_params *params)
> > {
> > return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) && params->attach_ops &&
> > - params->attach_ops->move_notify;
> > + params->attach_ops->invalidate_mappings;
> > }
> >
> > static void check_residency(struct kunit *test, struct xe_bo *exported,
> > @@ -60,7 +60,7 @@ static void check_residency(struct kunit *test, struct xe_bo *exported,
> >
> > /*
> > * Evict exporter. Evicting the exported bo will
> > - * evict also the imported bo through the move_notify() functionality if
> > + * evict also the imported bo through the invalidate_mappings() functionality if
> > * importer is on a different device. If they're on the same device,
> > * the exporter and the importer should be the same bo.
> > */
> > @@ -198,7 +198,7 @@ static void xe_test_dmabuf_import_same_driver(struct xe_device *xe)
> >
> > static const struct dma_buf_attach_ops nop2p_attach_ops = {
> > .allow_peer2peer = false,
> > - .move_notify = xe_dma_buf_move_notify
> > + .invalidate_mappings = xe_dma_buf_move_notify
> > };
> >
> > /*
> > diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
> > index 7c74a31d4486..1b9cd043e517 100644
> > --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> > +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> > @@ -287,7 +287,7 @@ static void xe_dma_buf_move_notify(struct dma_buf_attachment *attach)
> >
> > static const struct dma_buf_attach_ops xe_dma_buf_attach_ops = {
> > .allow_peer2peer = true,
> > - .move_notify = xe_dma_buf_move_notify
> > + .invalidate_mappings = xe_dma_buf_move_notify
> > };
> >
> > #if IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST)
> > diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c
> > index 0ec2e4120cc9..d77a739cfe7a 100644
> > --- a/drivers/infiniband/core/umem_dmabuf.c
> > +++ b/drivers/infiniband/core/umem_dmabuf.c
> > @@ -129,7 +129,7 @@ ib_umem_dmabuf_get_with_dma_device(struct ib_device *device,
> > if (check_add_overflow(offset, (unsigned long)size, &end))
> > return ret;
> >
> > - if (unlikely(!ops || !ops->move_notify))
> > + if (unlikely(!ops || !ops->invalidate_mappings))
> > return ret;
> >
> > dmabuf = dma_buf_get(fd);
> > @@ -195,7 +195,7 @@ ib_umem_dmabuf_unsupported_move_notify(struct dma_buf_attachment *attach)
> >
> > static struct dma_buf_attach_ops ib_umem_dmabuf_attach_pinned_ops = {
> > .allow_peer2peer = true,
> > - .move_notify = ib_umem_dmabuf_unsupported_move_notify,
> > + .invalidate_mappings = ib_umem_dmabuf_unsupported_move_notify,
> > };
> >
> > struct ib_umem_dmabuf *
> > diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
> > index 325fa04cbe8a..97099d3b1688 100644
> > --- a/drivers/infiniband/hw/mlx5/mr.c
> > +++ b/drivers/infiniband/hw/mlx5/mr.c
> > @@ -1620,7 +1620,7 @@ static void mlx5_ib_dmabuf_invalidate_cb(struct dma_buf_attachment *attach)
> >
> > static struct dma_buf_attach_ops mlx5_ib_dmabuf_attach_ops = {
> > .allow_peer2peer = 1,
> > - .move_notify = mlx5_ib_dmabuf_invalidate_cb,
> > + .invalidate_mappings = mlx5_ib_dmabuf_invalidate_cb,
> > };
> >
> > static struct ib_mr *
> > diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c
> > index dbe51ecb9a20..76f900fa1687 100644
> > --- a/drivers/iommu/iommufd/pages.c
> > +++ b/drivers/iommu/iommufd/pages.c
> > @@ -1451,7 +1451,7 @@ static void iopt_revoke_notify(struct dma_buf_attachment *attach)
> >
> > static struct dma_buf_attach_ops iopt_dmabuf_attach_revoke_ops = {
> > .allow_peer2peer = true,
> > - .move_notify = iopt_revoke_notify,
> > + .invalidate_mappings = iopt_revoke_notify,
> > };
> >
> > /*
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index 0bc492090237..1b397635c793 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -407,7 +407,7 @@ struct dma_buf {
> > * through the device.
> > *
> > * - Dynamic importers should set fences for any access that they can't
> > - * disable immediately from their &dma_buf_attach_ops.move_notify
> > + * disable immediately from their &dma_buf_attach_ops.invalidate_mappings
> > * callback.
> > *
> > * IMPORTANT:
> > @@ -458,7 +458,7 @@ struct dma_buf_attach_ops {
> > bool allow_peer2peer;
> >
> > /**
> > - * @move_notify: [optional] notification that the DMA-buf is moving
> > + * @invalidate_mappings: [optional] notification that the DMA-buf is moving
> > *
> > * If this callback is provided the framework can avoid pinning the
> > * backing store while mappings exists.
> > @@ -475,7 +475,7 @@ struct dma_buf_attach_ops {
> > * 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);
> > + void (*invalidate_mappings)(struct dma_buf_attachment *attach);
> > };
> >
> > /**
> >
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 1/4] dma-buf: Rename .move_notify() callback to a clearer identifier
2026-01-19 11:38 ` Leon Romanovsky
@ 2026-01-19 12:00 ` Christian König
2026-01-19 12:39 ` Leon Romanovsky
0 siblings, 1 reply; 37+ messages in thread
From: Christian König @ 2026-01-19 12:00 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Sumit Semwal, Alex Deucher, David Airlie, Simona Vetter,
Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh, Chia-I Wu,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, amd-gfx, virtualization, intel-xe,
linux-rdma, iommu, kvm
On 1/19/26 12:38, Leon Romanovsky wrote:
> On Mon, Jan 19, 2026 at 11:22:27AM +0100, Christian König wrote:
>> On 1/18/26 13:08, Leon Romanovsky wrote:
>>> From: Leon Romanovsky <leonro@nvidia.com>
>>>
>>> Rename the .move_notify() callback to .invalidate_mappings() to make its
>>> purpose explicit and highlight that it is responsible for invalidating
>>> existing mappings.
>>>
>>> Suggested-by: Christian König <christian.koenig@amd.com>
>>> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
>>
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>
> Thanks,
>
> BTW, I didn't update the various xxx_move_notify() functions to use
> xxx_invalidate_mappings() names. Should those be converted as well?
No, those importer specific functions can keep their name.
More important is the config option. Haven't thought about that one.
Probably best if we either rename or completely remove that one, it was to keep the MOVE_NOTIFY functionality separate for initial testing but we have clearly supassed this long time ago.
Regards,
Christian.
>
>>
>>> ---
>>> drivers/dma-buf/dma-buf.c | 6 +++---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
>>> drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
>>> drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
>>> drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
>>> drivers/infiniband/core/umem_dmabuf.c | 4 ++--
>>> drivers/infiniband/hw/mlx5/mr.c | 2 +-
>>> drivers/iommu/iommufd/pages.c | 2 +-
>>> include/linux/dma-buf.h | 6 +++---
>>> 9 files changed, 17 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index edaa9e4ee4ae..59cc647bf40e 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -948,7 +948,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
>>> if (WARN_ON(!dmabuf || !dev))
>>> return ERR_PTR(-EINVAL);
>>>
>>> - if (WARN_ON(importer_ops && !importer_ops->move_notify))
>>> + if (WARN_ON(importer_ops && !importer_ops->invalidate_mappings))
>>> return ERR_PTR(-EINVAL);
>>>
>>> attach = kzalloc(sizeof(*attach), GFP_KERNEL);
>>> @@ -1055,7 +1055,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_pin, "DMA_BUF");
>>> *
>>> * This unpins a buffer pinned by dma_buf_pin() and allows the exporter to move
>>> * any mapping of @attach again and inform the importer through
>>> - * &dma_buf_attach_ops.move_notify.
>>> + * &dma_buf_attach_ops.invalidate_mappings.
>>> */
>>> void dma_buf_unpin(struct dma_buf_attachment *attach)
>>> {
>>> @@ -1262,7 +1262,7 @@ void dma_buf_move_notify(struct dma_buf *dmabuf)
>>>
>>> list_for_each_entry(attach, &dmabuf->attachments, node)
>>> if (attach->importer_ops)
>>> - attach->importer_ops->move_notify(attach);
>>> + attach->importer_ops->invalidate_mappings(attach);
>>> }
>>> EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, "DMA_BUF");
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>>> index e22cfa7c6d32..863454148b28 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
>>> @@ -450,7 +450,7 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
>>> }
>>>
>>> /**
>>> - * amdgpu_dma_buf_move_notify - &attach.move_notify implementation
>>> + * amdgpu_dma_buf_move_notify - &attach.invalidate_mappings implementation
>>> *
>>> * @attach: the DMA-buf attachment
>>> *
>>> @@ -521,7 +521,7 @@ amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
>>>
>>> static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
>>> .allow_peer2peer = true,
>>> - .move_notify = amdgpu_dma_buf_move_notify
>>> + .invalidate_mappings = amdgpu_dma_buf_move_notify
>>> };
>>>
>>> /**
>>> diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c
>>> index ce49282198cb..19c78dd2ca77 100644
>>> --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
>>> +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
>>> @@ -288,7 +288,7 @@ static void virtgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
>>>
>>> static const struct dma_buf_attach_ops virtgpu_dma_buf_attach_ops = {
>>> .allow_peer2peer = true,
>>> - .move_notify = virtgpu_dma_buf_move_notify
>>> + .invalidate_mappings = virtgpu_dma_buf_move_notify
>>> };
>>>
>>> struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev,
>>> diff --git a/drivers/gpu/drm/xe/tests/xe_dma_buf.c b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
>>> index 5df98de5ba3c..1f2cca5c2f81 100644
>>> --- a/drivers/gpu/drm/xe/tests/xe_dma_buf.c
>>> +++ b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
>>> @@ -23,7 +23,7 @@ static bool p2p_enabled(struct dma_buf_test_params *params)
>>> static bool is_dynamic(struct dma_buf_test_params *params)
>>> {
>>> return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) && params->attach_ops &&
>>> - params->attach_ops->move_notify;
>>> + params->attach_ops->invalidate_mappings;
>>> }
>>>
>>> static void check_residency(struct kunit *test, struct xe_bo *exported,
>>> @@ -60,7 +60,7 @@ static void check_residency(struct kunit *test, struct xe_bo *exported,
>>>
>>> /*
>>> * Evict exporter. Evicting the exported bo will
>>> - * evict also the imported bo through the move_notify() functionality if
>>> + * evict also the imported bo through the invalidate_mappings() functionality if
>>> * importer is on a different device. If they're on the same device,
>>> * the exporter and the importer should be the same bo.
>>> */
>>> @@ -198,7 +198,7 @@ static void xe_test_dmabuf_import_same_driver(struct xe_device *xe)
>>>
>>> static const struct dma_buf_attach_ops nop2p_attach_ops = {
>>> .allow_peer2peer = false,
>>> - .move_notify = xe_dma_buf_move_notify
>>> + .invalidate_mappings = xe_dma_buf_move_notify
>>> };
>>>
>>> /*
>>> diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
>>> index 7c74a31d4486..1b9cd043e517 100644
>>> --- a/drivers/gpu/drm/xe/xe_dma_buf.c
>>> +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
>>> @@ -287,7 +287,7 @@ static void xe_dma_buf_move_notify(struct dma_buf_attachment *attach)
>>>
>>> static const struct dma_buf_attach_ops xe_dma_buf_attach_ops = {
>>> .allow_peer2peer = true,
>>> - .move_notify = xe_dma_buf_move_notify
>>> + .invalidate_mappings = xe_dma_buf_move_notify
>>> };
>>>
>>> #if IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST)
>>> diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c
>>> index 0ec2e4120cc9..d77a739cfe7a 100644
>>> --- a/drivers/infiniband/core/umem_dmabuf.c
>>> +++ b/drivers/infiniband/core/umem_dmabuf.c
>>> @@ -129,7 +129,7 @@ ib_umem_dmabuf_get_with_dma_device(struct ib_device *device,
>>> if (check_add_overflow(offset, (unsigned long)size, &end))
>>> return ret;
>>>
>>> - if (unlikely(!ops || !ops->move_notify))
>>> + if (unlikely(!ops || !ops->invalidate_mappings))
>>> return ret;
>>>
>>> dmabuf = dma_buf_get(fd);
>>> @@ -195,7 +195,7 @@ ib_umem_dmabuf_unsupported_move_notify(struct dma_buf_attachment *attach)
>>>
>>> static struct dma_buf_attach_ops ib_umem_dmabuf_attach_pinned_ops = {
>>> .allow_peer2peer = true,
>>> - .move_notify = ib_umem_dmabuf_unsupported_move_notify,
>>> + .invalidate_mappings = ib_umem_dmabuf_unsupported_move_notify,
>>> };
>>>
>>> struct ib_umem_dmabuf *
>>> diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
>>> index 325fa04cbe8a..97099d3b1688 100644
>>> --- a/drivers/infiniband/hw/mlx5/mr.c
>>> +++ b/drivers/infiniband/hw/mlx5/mr.c
>>> @@ -1620,7 +1620,7 @@ static void mlx5_ib_dmabuf_invalidate_cb(struct dma_buf_attachment *attach)
>>>
>>> static struct dma_buf_attach_ops mlx5_ib_dmabuf_attach_ops = {
>>> .allow_peer2peer = 1,
>>> - .move_notify = mlx5_ib_dmabuf_invalidate_cb,
>>> + .invalidate_mappings = mlx5_ib_dmabuf_invalidate_cb,
>>> };
>>>
>>> static struct ib_mr *
>>> diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c
>>> index dbe51ecb9a20..76f900fa1687 100644
>>> --- a/drivers/iommu/iommufd/pages.c
>>> +++ b/drivers/iommu/iommufd/pages.c
>>> @@ -1451,7 +1451,7 @@ static void iopt_revoke_notify(struct dma_buf_attachment *attach)
>>>
>>> static struct dma_buf_attach_ops iopt_dmabuf_attach_revoke_ops = {
>>> .allow_peer2peer = true,
>>> - .move_notify = iopt_revoke_notify,
>>> + .invalidate_mappings = iopt_revoke_notify,
>>> };
>>>
>>> /*
>>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>>> index 0bc492090237..1b397635c793 100644
>>> --- a/include/linux/dma-buf.h
>>> +++ b/include/linux/dma-buf.h
>>> @@ -407,7 +407,7 @@ struct dma_buf {
>>> * through the device.
>>> *
>>> * - Dynamic importers should set fences for any access that they can't
>>> - * disable immediately from their &dma_buf_attach_ops.move_notify
>>> + * disable immediately from their &dma_buf_attach_ops.invalidate_mappings
>>> * callback.
>>> *
>>> * IMPORTANT:
>>> @@ -458,7 +458,7 @@ struct dma_buf_attach_ops {
>>> bool allow_peer2peer;
>>>
>>> /**
>>> - * @move_notify: [optional] notification that the DMA-buf is moving
>>> + * @invalidate_mappings: [optional] notification that the DMA-buf is moving
>>> *
>>> * If this callback is provided the framework can avoid pinning the
>>> * backing store while mappings exists.
>>> @@ -475,7 +475,7 @@ struct dma_buf_attach_ops {
>>> * 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);
>>> + void (*invalidate_mappings)(struct dma_buf_attachment *attach);
>>> };
>>>
>>> /**
>>>
>>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 1/4] dma-buf: Rename .move_notify() callback to a clearer identifier
2026-01-19 12:00 ` Christian König
@ 2026-01-19 12:39 ` Leon Romanovsky
0 siblings, 0 replies; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 12:39 UTC (permalink / raw)
To: Christian König
Cc: Sumit Semwal, Alex Deucher, David Airlie, Simona Vetter,
Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh, Chia-I Wu,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, amd-gfx, virtualization, intel-xe,
linux-rdma, iommu, kvm
On Mon, Jan 19, 2026 at 01:00:18PM +0100, Christian König wrote:
> On 1/19/26 12:38, Leon Romanovsky wrote:
> > On Mon, Jan 19, 2026 at 11:22:27AM +0100, Christian König wrote:
> >> On 1/18/26 13:08, Leon Romanovsky wrote:
> >>> From: Leon Romanovsky <leonro@nvidia.com>
> >>>
> >>> Rename the .move_notify() callback to .invalidate_mappings() to make its
> >>> purpose explicit and highlight that it is responsible for invalidating
> >>> existing mappings.
> >>>
> >>> Suggested-by: Christian König <christian.koenig@amd.com>
> >>> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> >>
> >> Reviewed-by: Christian König <christian.koenig@amd.com>
> >
> > Thanks,
> >
> > BTW, I didn't update the various xxx_move_notify() functions to use
> > xxx_invalidate_mappings() names. Should those be converted as well?
>
> No, those importer specific functions can keep their name.
>
> More important is the config option. Haven't thought about that one.
>
> Probably best if we either rename or completely remove that one, it was to keep the MOVE_NOTIFY functionality separate for initial testing but we have clearly supassed this long time ago.
I removed it and will send in v3.
commit 05ad416fc0b8c9b07714f9b23dbb038c991b819d
Author: Leon Romanovsky <leonro@nvidia.com>
Date: Mon Jan 19 07:24:26 2026 -0500
dma-buf: Always build with DMABUF_MOVE_NOTIFY
DMABUF_MOVE_NOTIFY was introduced in 2018 and has been marked as
experimental and disabled by default ever since. Six years later,
all new importers implement this callback.
It is therefore reasonable to drop CONFIG_DMABUF_MOVE_NOTIFY and
always build DMABUF with support for it enabled.
Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index b46eb8a552d7..84d5e9b24e20 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -40,18 +40,6 @@ config UDMABUF
A driver to let userspace turn memfd regions into dma-bufs.
Qemu can use this to create host dmabufs for guest framebuffers.
-config DMABUF_MOVE_NOTIFY
- bool "Move notify between drivers (EXPERIMENTAL)"
- default n
- depends on DMA_SHARED_BUFFER
- help
- Don't pin buffers if the dynamic DMA-buf interface is available on
- both the exporter as well as the importer. This fixes a security
- problem where userspace is able to pin unrestricted amounts of memory
- through DMA-buf.
- This is marked experimental because we don't yet have a consistent
- execution context and memory management between drivers.
-
config DMABUF_DEBUG
bool "DMA-BUF debug checks"
depends on DMA_SHARED_BUFFER
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 59cc647bf40e..cd3b60ce4863 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -837,18 +837,10 @@ static void mangle_sg_table(struct sg_table *sg_table)
}
-static inline bool
-dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
-{
- return !!attach->importer_ops;
-}
-
static bool
dma_buf_pin_on_map(struct dma_buf_attachment *attach)
{
- return attach->dmabuf->ops->pin &&
- (!dma_buf_attachment_is_dynamic(attach) ||
- !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY));
+ return attach->dmabuf->ops->pin && !attach->importer_ops;
}
/**
@@ -1124,7 +1116,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
/*
* Importers with static attachments don't wait for fences.
*/
- if (!dma_buf_attachment_is_dynamic(attach)) {
+ if (!attach->importer_ops) {
ret = dma_resv_wait_timeout(attach->dmabuf->resv,
DMA_RESV_USAGE_KERNEL, true,
MAX_SCHEDULE_TIMEOUT);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 863454148b28..349215549e8f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -145,13 +145,9 @@ static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
* notifiers are disabled, only allow pinning in VRAM when move
* notiers are enabled.
*/
- if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
- domains &= ~AMDGPU_GEM_DOMAIN_VRAM;
- } else {
- list_for_each_entry(attach, &dmabuf->attachments, node)
- if (!attach->peer2peer)
- domains &= ~AMDGPU_GEM_DOMAIN_VRAM;
- }
+ list_for_each_entry(attach, &dmabuf->attachments, node)
+ if (!attach->peer2peer)
+ domains &= ~AMDGPU_GEM_DOMAIN_VRAM;
if (domains & AMDGPU_GEM_DOMAIN_VRAM)
bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig b/drivers/gpu/drm/amd/amdkfd/Kconfig
index 16e12c9913f9..a5d7467c2f34 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -27,7 +27,7 @@ config HSA_AMD_SVM
config HSA_AMD_P2P
bool "HSA kernel driver support for peer-to-peer for AMD GPU devices"
- depends on HSA_AMD && PCI_P2PDMA && DMABUF_MOVE_NOTIFY
+ depends on HSA_AMD && PCI_P2PDMA
help
Enable peer-to-peer (P2P) communication between AMD GPUs over
the PCIe bus. This can improve performance of multi-GPU compute
diff --git a/drivers/gpu/drm/xe/tests/xe_dma_buf.c b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
index 1f2cca5c2f81..c107687ef3c0 100644
--- a/drivers/gpu/drm/xe/tests/xe_dma_buf.c
+++ b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
@@ -22,8 +22,7 @@ static bool p2p_enabled(struct dma_buf_test_params *params)
static bool is_dynamic(struct dma_buf_test_params *params)
{
- return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) && params->attach_ops &&
- params->attach_ops->invalidate_mappings;
+ return params->attach_ops && params->attach_ops->invalidate_mappings;
}
static void check_residency(struct kunit *test, struct xe_bo *exported,
diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
index 1b9cd043e517..ea370cd373e9 100644
--- a/drivers/gpu/drm/xe/xe_dma_buf.c
+++ b/drivers/gpu/drm/xe/xe_dma_buf.c
@@ -56,14 +56,10 @@ static int xe_dma_buf_pin(struct dma_buf_attachment *attach)
bool allow_vram = true;
int ret;
- if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
- allow_vram = false;
- } else {
- list_for_each_entry(attach, &dmabuf->attachments, node) {
- if (!attach->peer2peer) {
- allow_vram = false;
- break;
- }
+ list_for_each_entry(attach, &dmabuf->attachments, node) {
+ if (!attach->peer2peer) {
+ allow_vram = false;
+ break;
}
}
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v2 2/4] dma-buf: Document revoke semantics
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
2026-01-18 12:08 ` [PATCH v2 1/4] dma-buf: Rename .move_notify() callback to a clearer identifier Leon Romanovsky
@ 2026-01-18 12:08 ` Leon Romanovsky
2026-01-18 14:29 ` Thomas Hellström
` (3 more replies)
2026-01-18 12:08 ` [PATCH v2 3/4] iommufd: Require DMABUF " Leon Romanovsky
` (7 subsequent siblings)
9 siblings, 4 replies; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-18 12:08 UTC (permalink / raw)
To: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Leon Romanovsky, Kevin Tian, Joerg Roedel,
Will Deacon, Robin Murphy, Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
From: Leon Romanovsky <leonro@nvidia.com>
Document a DMA-buf revoke mechanism that allows an exporter to explicitly
invalidate ("kill") a shared buffer after it has been handed out to
importers. Once revoked, all further CPU and device access is blocked, and
importers consistently observe failure.
This requires both importers and exporters to honor the revoke contract.
For importers, this means implementing .invalidate_mappings() and calling
dma_buf_pin() after the DMA‑buf is attached to verify the exporter’s support
for revocation.
For exporters, this means implementing the .pin() callback, which checks
the DMA‑buf attachment for a valid revoke implementation.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
include/linux/dma-buf.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 1b397635c793..e0bc0b7119f5 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -579,6 +579,25 @@ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
return !!dmabuf->ops->pin;
}
+/**
+ * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements
+ * revoke semantics.
+ * @attach: the DMA-buf attachment to check
+ *
+ * Returns true if DMA-buf importer honors revoke semantics, which is
+ * negotiated with the exporter, by making sure that importer implements
+ * .invalidate_mappings() callback and calls to dma_buf_pin() after
+ * DMA-buf attach.
+ */
+static inline bool
+dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
+{
+ return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) &&
+ dma_buf_is_dynamic(attach->dmabuf) &&
+ (attach->importer_ops &&
+ attach->importer_ops->invalidate_mappings);
+}
+
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
struct dma_buf_attachment *
--
2.52.0
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v2 2/4] dma-buf: Document revoke semantics
2026-01-18 12:08 ` [PATCH v2 2/4] dma-buf: Document revoke semantics Leon Romanovsky
@ 2026-01-18 14:29 ` Thomas Hellström
2026-01-19 9:04 ` Leon Romanovsky
2026-01-18 21:40 ` John Hubbard
` (2 subsequent siblings)
3 siblings, 1 reply; 37+ messages in thread
From: Thomas Hellström @ 2026-01-18 14:29 UTC (permalink / raw)
To: Leon Romanovsky, Sumit Semwal, Christian König, Alex Deucher,
David Airlie, Simona Vetter, Gerd Hoffmann, Dmitry Osipenko,
Gurchetan Singh, Chia-I Wu, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Lucas De Marchi, Rodrigo Vivi, Jason Gunthorpe,
Kevin Tian, Joerg Roedel, Will Deacon, Robin Murphy,
Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> Document a DMA-buf revoke mechanism that allows an exporter to
> explicitly
> invalidate ("kill") a shared buffer after it has been handed out to
> importers. Once revoked, all further CPU and device access is
> blocked, and
> importers consistently observe failure.
See previous comment WRT this.
>
> This requires both importers and exporters to honor the revoke
> contract.
>
> For importers, this means implementing .invalidate_mappings() and
> calling
> dma_buf_pin() after the DMA‑buf is attached to verify the exporter’s
> support
> for revocation.
Why would the importer want to verify the exporter's support for
revocation? If the exporter doesn't support it, the only consequence
would be that invalidate_mappings() would never be called, and that
dma_buf_pin() is a NOP. Besides, dma_buf_pin() would not return an
error if the exporter doesn't implement the pin() callback?
Or perhaps I missed a prereq patch?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 2/4] dma-buf: Document revoke semantics
2026-01-18 14:29 ` Thomas Hellström
@ 2026-01-19 9:04 ` Leon Romanovsky
0 siblings, 0 replies; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 9:04 UTC (permalink / raw)
To: Thomas Hellström
Cc: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Rodrigo Vivi, Jason Gunthorpe, Kevin Tian,
Joerg Roedel, Will Deacon, Robin Murphy, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On Sun, Jan 18, 2026 at 03:29:02PM +0100, Thomas Hellström wrote:
> On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > Document a DMA-buf revoke mechanism that allows an exporter to
> > explicitly
> > invalidate ("kill") a shared buffer after it has been handed out to
> > importers. Once revoked, all further CPU and device access is
> > blocked, and
> > importers consistently observe failure.
>
> See previous comment WRT this.
>
> >
> > This requires both importers and exporters to honor the revoke
> > contract.
> >
> > For importers, this means implementing .invalidate_mappings() and
> > calling
> > dma_buf_pin() after the DMA‑buf is attached to verify the exporter’s
> > support
> > for revocation.
>
> Why would the importer want to verify the exporter's support for
> revocation? If the exporter doesn't support it, the only consequence
> would be that invalidate_mappings() would never be called, and that
> dma_buf_pin() is a NOP. Besides, dma_buf_pin() would not return an
> error if the exporter doesn't implement the pin() callback?
The idea is that both should do revoke and there is a need to indicate
that this exporter has some expectations from the importers. One of them
is that invalidate_mappings exists.
Thanks
>
> Or perhaps I missed a prereq patch?
>
> Thanks,
> Thomas
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v2 2/4] dma-buf: Document revoke semantics
2026-01-18 12:08 ` [PATCH v2 2/4] dma-buf: Document revoke semantics Leon Romanovsky
2026-01-18 14:29 ` Thomas Hellström
@ 2026-01-18 21:40 ` John Hubbard
2026-01-19 7:25 ` Leon Romanovsky
2026-01-19 10:56 ` Christian König
[not found] ` <20260119164421.GF961572@ziepe.ca>
3 siblings, 1 reply; 37+ messages in thread
From: John Hubbard @ 2026-01-18 21:40 UTC (permalink / raw)
To: Leon Romanovsky, Sumit Semwal, Christian König, Alex Deucher,
David Airlie, Simona Vetter, Gerd Hoffmann, Dmitry Osipenko,
Gurchetan Singh, Chia-I Wu, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Lucas De Marchi, Thomas Hellström,
Rodrigo Vivi, Jason Gunthorpe, Kevin Tian, Joerg Roedel,
Will Deacon, Robin Murphy, Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On 1/18/26 4:08 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
...
> +/**
> + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements
> + * revoke semantics.
> + * @attach: the DMA-buf attachment to check
> + *
> + * Returns true if DMA-buf importer honors revoke semantics, which is
> + * negotiated with the exporter, by making sure that importer implements
> + * .invalidate_mappings() callback and calls to dma_buf_pin() after
> + * DMA-buf attach.
> + */
> +static inline bool
> +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
Maybe a slight rename, to dma_buf_attachment_is_revocable()?
thanks,
--
John Hubbard
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 2/4] dma-buf: Document revoke semantics
2026-01-18 21:40 ` John Hubbard
@ 2026-01-19 7:25 ` Leon Romanovsky
2026-01-19 7:32 ` John Hubbard
0 siblings, 1 reply; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 7:25 UTC (permalink / raw)
To: John Hubbard
Cc: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, amd-gfx, virtualization, intel-xe,
linux-rdma, iommu, kvm
On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote:
> On 1/18/26 4:08 AM, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> ...
> > +/**
> > + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements
> > + * revoke semantics.
> > + * @attach: the DMA-buf attachment to check
> > + *
> > + * Returns true if DMA-buf importer honors revoke semantics, which is
> > + * negotiated with the exporter, by making sure that importer implements
> > + * .invalidate_mappings() callback and calls to dma_buf_pin() after
> > + * DMA-buf attach.
> > + */
> > +static inline bool
> > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
>
> Maybe a slight rename, to dma_buf_attachment_is_revocable()?
I can do that. The issue is that even "dma_buf_attachment_is_revoke"
is already too long. :)
Thanks
>
>
> thanks,
> --
> John Hubbard
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v2 2/4] dma-buf: Document revoke semantics
2026-01-19 7:25 ` Leon Romanovsky
@ 2026-01-19 7:32 ` John Hubbard
2026-01-19 8:04 ` Leon Romanovsky
0 siblings, 1 reply; 37+ messages in thread
From: John Hubbard @ 2026-01-19 7:32 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, amd-gfx, virtualization, intel-xe,
linux-rdma, iommu, kvm
On 1/18/26 11:25 PM, Leon Romanovsky wrote:
> On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote:
>> On 1/18/26 4:08 AM, Leon Romanovsky wrote:
>>> From: Leon Romanovsky <leonro@nvidia.com>
>> ...
>>> +/**
>>> + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements
>>> + * revoke semantics.
>>> + * @attach: the DMA-buf attachment to check
>>> + *
>>> + * Returns true if DMA-buf importer honors revoke semantics, which is
>>> + * negotiated with the exporter, by making sure that importer implements
>>> + * .invalidate_mappings() callback and calls to dma_buf_pin() after
>>> + * DMA-buf attach.
>>> + */
>>> +static inline bool
>>> +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
>>
>> Maybe a slight rename, to dma_buf_attachment_is_revocable()?
>
> I can do that. The issue is that even "dma_buf_attachment_is_revoke"
> is already too long. :)
>
If you're really pressed for space for some reason, maybe
dma_buf_attach_revocable() ?
Just trying to hang on to the "revocable" part of the name, as
I think it's an improvement.
thanks,
--
John Hubbard
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v2 2/4] dma-buf: Document revoke semantics
2026-01-19 7:32 ` John Hubbard
@ 2026-01-19 8:04 ` Leon Romanovsky
0 siblings, 0 replies; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 8:04 UTC (permalink / raw)
To: John Hubbard
Cc: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, amd-gfx, virtualization, intel-xe,
linux-rdma, iommu, kvm
On Sun, Jan 18, 2026 at 11:32:20PM -0800, John Hubbard wrote:
> On 1/18/26 11:25 PM, Leon Romanovsky wrote:
> > On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote:
> > > On 1/18/26 4:08 AM, Leon Romanovsky wrote:
> > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > ...
> > > > +/**
> > > > + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements
> > > > + * revoke semantics.
> > > > + * @attach: the DMA-buf attachment to check
> > > > + *
> > > > + * Returns true if DMA-buf importer honors revoke semantics, which is
> > > > + * negotiated with the exporter, by making sure that importer implements
> > > > + * .invalidate_mappings() callback and calls to dma_buf_pin() after
> > > > + * DMA-buf attach.
> > > > + */
> > > > +static inline bool
> > > > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
> > >
> > > Maybe a slight rename, to dma_buf_attachment_is_revocable()?
> >
> > I can do that. The issue is that even "dma_buf_attachment_is_revoke"
> > is already too long. :)
> >
>
> If you're really pressed for space for some reason,
Mainly aesthetics.
> maybe dma_buf_attach_revocable() ?
>
> Just trying to hang on to the "revocable" part of the name, as
> I think it's an improvement.
Sure
>
> thanks,
> --
> John Hubbard
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v2 2/4] dma-buf: Document revoke semantics
2026-01-18 12:08 ` [PATCH v2 2/4] dma-buf: Document revoke semantics Leon Romanovsky
2026-01-18 14:29 ` Thomas Hellström
2026-01-18 21:40 ` John Hubbard
@ 2026-01-19 10:56 ` Christian König
2026-01-19 11:39 ` Leon Romanovsky
[not found] ` <20260119164421.GF961572@ziepe.ca>
3 siblings, 1 reply; 37+ messages in thread
From: Christian König @ 2026-01-19 10:56 UTC (permalink / raw)
To: Leon Romanovsky, Sumit Semwal, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On 1/18/26 13:08, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> Document a DMA-buf revoke mechanism that allows an exporter to explicitly
> invalidate ("kill") a shared buffer after it has been handed out to
> importers. Once revoked, all further CPU and device access is blocked, and
> importers consistently observe failure.
>
> This requires both importers and exporters to honor the revoke contract.
>
> For importers, this means implementing .invalidate_mappings() and calling
> dma_buf_pin() after the DMA‑buf is attached to verify the exporter’s support
> for revocation.
>
> For exporters, this means implementing the .pin() callback, which checks
> the DMA‑buf attachment for a valid revoke implementation.
>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> include/linux/dma-buf.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 1b397635c793..e0bc0b7119f5 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -579,6 +579,25 @@ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
> return !!dmabuf->ops->pin;
> }
>
> +/**
> + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements
> + * revoke semantics.
> + * @attach: the DMA-buf attachment to check
> + *
> + * Returns true if DMA-buf importer honors revoke semantics, which is
> + * negotiated with the exporter, by making sure that importer implements
> + * .invalidate_mappings() callback and calls to dma_buf_pin() after
> + * DMA-buf attach.
That wording is to unclear. Something like:
Returns true if the DMA-buf importer can handle invalidating it's mappings at any time, even after pinning a buffer.
> + */
> +static inline bool
> +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
That's clearly not a good name. But that is already discussed in another thread.
> +{
> + return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) &&
Oh, we should have renamed that as well. Or maybe it is time to completely remove that config option.
> + dma_buf_is_dynamic(attach->dmabuf) &&
This is checking exporter and not importer capabilities, please drop.
> + (attach->importer_ops &&
> + attach->importer_ops->invalidate_mappings);
So when invalidate_mappings is implemented we need to be able to call it at any time. Yeah that sounds like a valid approach to me.
But we need to remove the RDNA callback with the warning then to properly signal that. And also please document that in the callback kerneldoc.
Regards,
Christian.
> +}
> +
> struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> struct device *dev);
> struct dma_buf_attachment *
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 2/4] dma-buf: Document revoke semantics
2026-01-19 10:56 ` Christian König
@ 2026-01-19 11:39 ` Leon Romanovsky
0 siblings, 0 replies; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 11:39 UTC (permalink / raw)
To: Christian König
Cc: Sumit Semwal, Alex Deucher, David Airlie, Simona Vetter,
Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh, Chia-I Wu,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, amd-gfx, virtualization, intel-xe,
linux-rdma, iommu, kvm
On Mon, Jan 19, 2026 at 11:56:16AM +0100, Christian König wrote:
> On 1/18/26 13:08, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > Document a DMA-buf revoke mechanism that allows an exporter to explicitly
> > invalidate ("kill") a shared buffer after it has been handed out to
> > importers. Once revoked, all further CPU and device access is blocked, and
> > importers consistently observe failure.
> >
> > This requires both importers and exporters to honor the revoke contract.
> >
> > For importers, this means implementing .invalidate_mappings() and calling
> > dma_buf_pin() after the DMA‑buf is attached to verify the exporter’s support
> > for revocation.
> >
> > For exporters, this means implementing the .pin() callback, which checks
> > the DMA‑buf attachment for a valid revoke implementation.
> >
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > include/linux/dma-buf.h | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
<...>
> > + * Returns true if DMA-buf importer honors revoke semantics, which is
> > + * negotiated with the exporter, by making sure that importer implements
> > + * .invalidate_mappings() callback and calls to dma_buf_pin() after
> > + * DMA-buf attach.
>
> That wording is to unclear. Something like:
>
> Returns true if the DMA-buf importer can handle invalidating it's mappings at any time, even after pinning a buffer.
<...>
>
> That's clearly not a good name. But that is already discussed in another thread.
<...>
> Oh, we should have renamed that as well. Or maybe it is time to completely remove that config option.
<...>
> This is checking exporter and not importer capabilities, please drop.
<...>
> So when invalidate_mappings is implemented we need to be able to call it at any time. Yeah that sounds like a valid approach to me.
>
> But we need to remove the RDNA callback with the warning then to properly signal that. And also please document that in the callback kerneldoc.
Will do, thanks
>
> Regards,
> Christian.
>
> > +}
> > +
> > struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> > struct device *dev);
> > struct dma_buf_attachment *
> >
>
^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <20260119164421.GF961572@ziepe.ca>]
* Re: [PATCH v2 2/4] dma-buf: Document revoke semantics
[not found] ` <20260119164421.GF961572@ziepe.ca>
@ 2026-01-20 9:45 ` Leon Romanovsky
0 siblings, 0 replies; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-20 9:45 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi, Kevin Tian,
Joerg Roedel, Will Deacon, Robin Murphy, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On Mon, Jan 19, 2026 at 12:44:21PM -0400, Jason Gunthorpe wrote:
> On Sun, Jan 18, 2026 at 02:08:46PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > Document a DMA-buf revoke mechanism that allows an exporter to explicitly
> > invalidate ("kill") a shared buffer after it has been handed out to
> > importers. Once revoked, all further CPU and device access is blocked, and
> > importers consistently observe failure.
> >
> > This requires both importers and exporters to honor the revoke contract.
> >
> > For importers, this means implementing .invalidate_mappings() and calling
> > dma_buf_pin() after the DMA‑buf is attached to verify the exporter’s support
> > for revocation.
> >
> > For exporters, this means implementing the .pin() callback, which checks
> > the DMA‑buf attachment for a valid revoke implementation.
> >
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > include/linux/dma-buf.h | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index 1b397635c793..e0bc0b7119f5 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -579,6 +579,25 @@ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
> > return !!dmabuf->ops->pin;
> > }
> >
> > +/**
> > + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements
> > + * revoke semantics.
> > + * @attach: the DMA-buf attachment to check
> > + *
> > + * Returns true if DMA-buf importer honors revoke semantics, which is
> > + * negotiated with the exporter, by making sure that importer implements
> > + * .invalidate_mappings() callback and calls to dma_buf_pin() after
> > + * DMA-buf attach.
> > + */
>
> I think this clarification should also have comment to
> dma_buf_move_notify(). Maybe like this:
>
> @@ -1324,7 +1324,18 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_sgt_unmap_attachment_unlocked, "DMA_BUF");
> * @dmabuf: [in] buffer which is moving
> *
> * Informs all attachments that they need to destroy and recreate all their
> - * mappings.
> + * mappings. If the attachment is dynamic then the dynamic importer is expected
> + * to invalidate any caches it has of the mapping result and perform a new
> + * mapping request before allowing HW to do any further DMA.
> + *
> + * If the attachment is pinned then this informs the pinned importer that
> + * the underlying mapping is no longer available. Pinned importers may take
> + * this is as a permanent revocation so exporters should not trigger it
> + * lightly.
> + *
> + * For legacy pinned importers that cannot support invalidation this is a NOP.
> + * Drivers can call dma_buf_attachment_is_revoke() to determine if the
> + * importer supports this.
> */
>
> Also it would be nice to document what Christian pointed out regarding
> fences after move_notify.
I added this comment too:
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6dd70f7b992d..478127dc63e9 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1253,6 +1253,10 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, "DMA_BUF");
* For legacy pinned importers that cannot support invalidation this is a NOP.
* Drivers can call dma_buf_attach_revocable() to determine if the importer
* supports this.
+ *
+ * NOTE: The invalidation triggers asynchronous HW operation and the callers
+ * need to wait for this operation to complete by calling
+ * to dma_resv_wait_timeout().
*/
void dma_buf_move_notify(struct dma_buf *dmabuf)
{
>
> > +static inline bool
> > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
> > +{
> > + return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) &&
> > + dma_buf_is_dynamic(attach->dmabuf) &&
> > + (attach->importer_ops &&
> > + attach->importer_ops->invalidate_mappings);
> > +}
>
> And I don't think we should use a NULL invalidate_mappings function
> pointer to signal this.
>
> It sounds like the direction is to require importers to support
> move_notify, so we should not make it easy to just drop a NULL in the
> ops struct to get out of the desired configuration.
>
> I suggest defining a function
> "dma_buf_unsupported_invalidate_mappings" and use
> EXPORT_SYMBOL_FOR_MODULES so only RDMA can use it. Then check for that
> along with NULL importer_ops to cover the two cases where it is not
> allowed.
>
> The only reason RDMA has to use dma_buf_dynamic_attach() is to set the
> allow_p2p=true ..
Will do.
>
> Jason
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v2 3/4] iommufd: Require DMABUF revoke semantics
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
2026-01-18 12:08 ` [PATCH v2 1/4] dma-buf: Rename .move_notify() callback to a clearer identifier Leon Romanovsky
2026-01-18 12:08 ` [PATCH v2 2/4] dma-buf: Document revoke semantics Leon Romanovsky
@ 2026-01-18 12:08 ` Leon Romanovsky
[not found] ` <20260119165951.GI961572@ziepe.ca>
2026-01-18 12:08 ` [PATCH v2 4/4] vfio: Add pinned interface to perform " Leon Romanovsky
` (6 subsequent siblings)
9 siblings, 1 reply; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-18 12:08 UTC (permalink / raw)
To: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Leon Romanovsky, Kevin Tian, Joerg Roedel,
Will Deacon, Robin Murphy, Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
From: Leon Romanovsky <leonro@nvidia.com>
IOMMUFD does not support page fault handling, and after a call to
.invalidate_mappings() all mappings become invalid. Ensure that
the IOMMUFD DMABUF importer is bound to a revoke‑aware DMABUF exporter
(for example, VFIO).
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/iommu/iommufd/pages.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c
index 76f900fa1687..a5eb2bc4ef48 100644
--- a/drivers/iommu/iommufd/pages.c
+++ b/drivers/iommu/iommufd/pages.c
@@ -1501,16 +1501,22 @@ static int iopt_map_dmabuf(struct iommufd_ctx *ictx, struct iopt_pages *pages,
mutex_unlock(&pages->mutex);
}
- rc = sym_vfio_pci_dma_buf_iommufd_map(attach, &pages->dmabuf.phys);
+ rc = dma_buf_pin(attach);
if (rc)
goto err_detach;
+ rc = sym_vfio_pci_dma_buf_iommufd_map(attach, &pages->dmabuf.phys);
+ if (rc)
+ goto err_unpin;
+
dma_resv_unlock(dmabuf->resv);
/* On success iopt_release_pages() will detach and put the dmabuf. */
pages->dmabuf.attach = attach;
return 0;
+err_unpin:
+ dma_buf_unpin(attach);
err_detach:
dma_resv_unlock(dmabuf->resv);
dma_buf_detach(dmabuf, attach);
@@ -1656,6 +1662,7 @@ void iopt_release_pages(struct kref *kref)
if (iopt_is_dmabuf(pages) && pages->dmabuf.attach) {
struct dma_buf *dmabuf = pages->dmabuf.attach->dmabuf;
+ dma_buf_unpin(pages->dmabuf.attach);
dma_buf_detach(dmabuf, pages->dmabuf.attach);
dma_buf_put(dmabuf);
WARN_ON(!list_empty(&pages->dmabuf.tracker));
--
2.52.0
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH v2 4/4] vfio: Add pinned interface to perform revoke semantics
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
` (2 preceding siblings ...)
2026-01-18 12:08 ` [PATCH v2 3/4] iommufd: Require DMABUF " Leon Romanovsky
@ 2026-01-18 12:08 ` Leon Romanovsky
2026-01-19 12:12 ` Christian König
2026-01-18 12:21 ` ✗ CI.checkpatch: warning for dma-buf: document revoke mechanism to invalidate shared buffers Patchwork
` (5 subsequent siblings)
9 siblings, 1 reply; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-18 12:08 UTC (permalink / raw)
To: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Leon Romanovsky, Kevin Tian, Joerg Roedel,
Will Deacon, Robin Murphy, Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
From: Leon Romanovsky <leonro@nvidia.com>
DMABUF ->pin() interface is called when the DMABUF importer perform
its DMA mapping, so let's use this opportunity to check if DMABUF
exporter revoked its buffer or not.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
index d4d0f7d08c53..af9c315ddf71 100644
--- a/drivers/vfio/pci/vfio_pci_dmabuf.c
+++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
@@ -20,6 +20,20 @@ struct vfio_pci_dma_buf {
u8 revoked : 1;
};
+static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
+{
+ struct vfio_pci_dma_buf *priv = attachment->dmabuf->priv;
+
+ dma_resv_assert_held(priv->dmabuf->resv);
+
+ return dma_buf_attachment_is_revoke(attachment) ? 0 : -EOPNOTSUPP;
+}
+
+static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
+{
+ /* Do nothing */
+}
+
static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
struct dma_buf_attachment *attachment)
{
@@ -76,6 +90,8 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
}
static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
+ .pin = vfio_pci_dma_buf_pin,
+ .unpin = vfio_pci_dma_buf_unpin,
.attach = vfio_pci_dma_buf_attach,
.map_dma_buf = vfio_pci_dma_buf_map,
.unmap_dma_buf = vfio_pci_dma_buf_unmap,
--
2.52.0
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v2 4/4] vfio: Add pinned interface to perform revoke semantics
2026-01-18 12:08 ` [PATCH v2 4/4] vfio: Add pinned interface to perform " Leon Romanovsky
@ 2026-01-19 12:12 ` Christian König
2026-01-19 13:02 ` Leon Romanovsky
0 siblings, 1 reply; 37+ messages in thread
From: Christian König @ 2026-01-19 12:12 UTC (permalink / raw)
To: Leon Romanovsky, Sumit Semwal, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On 1/18/26 13:08, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> DMABUF ->pin() interface is called when the DMABUF importer perform
> its DMA mapping, so let's use this opportunity to check if DMABUF
> exporter revoked its buffer or not.
>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> index d4d0f7d08c53..af9c315ddf71 100644
> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> @@ -20,6 +20,20 @@ struct vfio_pci_dma_buf {
> u8 revoked : 1;
> };
>
> +static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
> +{
> + struct vfio_pci_dma_buf *priv = attachment->dmabuf->priv;
> +
> + dma_resv_assert_held(priv->dmabuf->resv);
> +
> + return dma_buf_attachment_is_revoke(attachment) ? 0 : -EOPNOTSUPP;
It's probably better to do that check in vfio_pci_dma_buf_attach.
And BTW the function vfio_pci_dma_buf_move() seems to be broken:
void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked)
{
struct vfio_pci_dma_buf *priv;
struct vfio_pci_dma_buf *tmp;
lockdep_assert_held_write(&vdev->memory_lock);
list_for_each_entry_safe(priv, tmp, &vdev->dmabufs, dmabufs_elm) {
if (!get_file_active(&priv->dmabuf->file))
continue;
if (priv->revoked != revoked) {
dma_resv_lock(priv->dmabuf->resv, NULL);
priv->revoked = revoked;
dma_buf_move_notify(priv->dmabuf);
A dma_buf_move_notify() just triggers asynchronous invalidation of the mapping!
You need to use dma_resv_wait() to wait for that to finish.
dma_resv_unlock(priv->dmabuf->resv);
}
fput(priv->dmabuf->file);
}
}
Regards,
Christian.
> +}
> +
> +static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
> +{
> + /* Do nothing */
> +}
> +
> static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> struct dma_buf_attachment *attachment)
> {
> @@ -76,6 +90,8 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
> }
>
> static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
> + .pin = vfio_pci_dma_buf_pin,
> + .unpin = vfio_pci_dma_buf_unpin,
> .attach = vfio_pci_dma_buf_attach,
> .map_dma_buf = vfio_pci_dma_buf_map,
> .unmap_dma_buf = vfio_pci_dma_buf_unmap,
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 4/4] vfio: Add pinned interface to perform revoke semantics
2026-01-19 12:12 ` Christian König
@ 2026-01-19 13:02 ` Leon Romanovsky
2026-01-19 14:21 ` Christian König
0 siblings, 1 reply; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 13:02 UTC (permalink / raw)
To: Christian König
Cc: Sumit Semwal, Alex Deucher, David Airlie, Simona Vetter,
Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh, Chia-I Wu,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, amd-gfx, virtualization, intel-xe,
linux-rdma, iommu, kvm
On Mon, Jan 19, 2026 at 01:12:45PM +0100, Christian König wrote:
> On 1/18/26 13:08, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > DMABUF ->pin() interface is called when the DMABUF importer perform
> > its DMA mapping, so let's use this opportunity to check if DMABUF
> > exporter revoked its buffer or not.
> >
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > index d4d0f7d08c53..af9c315ddf71 100644
> > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > @@ -20,6 +20,20 @@ struct vfio_pci_dma_buf {
> > u8 revoked : 1;
> > };
> >
> > +static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
> > +{
> > + struct vfio_pci_dma_buf *priv = attachment->dmabuf->priv;
> > +
> > + dma_resv_assert_held(priv->dmabuf->resv);
> > +
> > + return dma_buf_attachment_is_revoke(attachment) ? 0 : -EOPNOTSUPP;
>
> It's probably better to do that check in vfio_pci_dma_buf_attach.
I assume you are proposing to add this check in both
vfio_pci_dma_buf_attach() and vfio_pci_dma_buf_pin(). Otherwise,
importers that lack .invalidate_mapping() will invoke dma_buf_pin()
and will not fail.
>
> And BTW the function vfio_pci_dma_buf_move() seems to be broken:
>
> void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked)
> {
> struct vfio_pci_dma_buf *priv;
> struct vfio_pci_dma_buf *tmp;
>
> lockdep_assert_held_write(&vdev->memory_lock);
>
> list_for_each_entry_safe(priv, tmp, &vdev->dmabufs, dmabufs_elm) {
> if (!get_file_active(&priv->dmabuf->file))
> continue;
>
> if (priv->revoked != revoked) {
> dma_resv_lock(priv->dmabuf->resv, NULL);
> priv->revoked = revoked;
> dma_buf_move_notify(priv->dmabuf);
>
> A dma_buf_move_notify() just triggers asynchronous invalidation of the mapping!
>
> You need to use dma_resv_wait() to wait for that to finish.
We (VFIO and IOMMUFD) followed the same pattern used in
amdgpu_bo_move_notify(), which also does not wait.
I'll add wait here.
Thanks
>
> dma_resv_unlock(priv->dmabuf->resv);
> }
> fput(priv->dmabuf->file);
> }
> }
>
> Regards,
> Christian.
>
>
> > +}
> > +
> > +static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
> > +{
> > + /* Do nothing */
> > +}
> > +
> > static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> > struct dma_buf_attachment *attachment)
> > {
> > @@ -76,6 +90,8 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
> > }
> >
> > static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
> > + .pin = vfio_pci_dma_buf_pin,
> > + .unpin = vfio_pci_dma_buf_unpin,
> > .attach = vfio_pci_dma_buf_attach,
> > .map_dma_buf = vfio_pci_dma_buf_map,
> > .unmap_dma_buf = vfio_pci_dma_buf_unmap,
> >
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 4/4] vfio: Add pinned interface to perform revoke semantics
2026-01-19 13:02 ` Leon Romanovsky
@ 2026-01-19 14:21 ` Christian König
0 siblings, 0 replies; 37+ messages in thread
From: Christian König @ 2026-01-19 14:21 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Sumit Semwal, Alex Deucher, David Airlie, Simona Vetter,
Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh, Chia-I Wu,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Thomas Hellström, Rodrigo Vivi,
Jason Gunthorpe, Kevin Tian, Joerg Roedel, Will Deacon,
Robin Murphy, Alex Williamson, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, amd-gfx, virtualization, intel-xe,
linux-rdma, iommu, kvm
On 1/19/26 14:02, Leon Romanovsky wrote:
> On Mon, Jan 19, 2026 at 01:12:45PM +0100, Christian König wrote:
>> On 1/18/26 13:08, Leon Romanovsky wrote:
>>> From: Leon Romanovsky <leonro@nvidia.com>
>>>
>>> DMABUF ->pin() interface is called when the DMABUF importer perform
>>> its DMA mapping, so let's use this opportunity to check if DMABUF
>>> exporter revoked its buffer or not.
>>>
>>> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
>>> ---
>>> drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
>>> index d4d0f7d08c53..af9c315ddf71 100644
>>> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
>>> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
>>> @@ -20,6 +20,20 @@ struct vfio_pci_dma_buf {
>>> u8 revoked : 1;
>>> };
>>>
>>> +static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
>>> +{
>>> + struct vfio_pci_dma_buf *priv = attachment->dmabuf->priv;
>>> +
>>> + dma_resv_assert_held(priv->dmabuf->resv);
>>> +
>>> + return dma_buf_attachment_is_revoke(attachment) ? 0 : -EOPNOTSUPP;
>>
>> It's probably better to do that check in vfio_pci_dma_buf_attach.
>
> I assume you are proposing to add this check in both
> vfio_pci_dma_buf_attach() and vfio_pci_dma_buf_pin(). Otherwise,
> importers that lack .invalidate_mapping() will invoke dma_buf_pin()
> and will not fail.
vfio_pci_dma_buf_attach() alone should be sufficient. It is always called, even for importers lacking invalidate_mapping().
Regards,
Christian.
>
>>
>> And BTW the function vfio_pci_dma_buf_move() seems to be broken:
>>
>> void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked)
>> {
>> struct vfio_pci_dma_buf *priv;
>> struct vfio_pci_dma_buf *tmp;
>>
>> lockdep_assert_held_write(&vdev->memory_lock);
>>
>> list_for_each_entry_safe(priv, tmp, &vdev->dmabufs, dmabufs_elm) {
>> if (!get_file_active(&priv->dmabuf->file))
>> continue;
>>
>> if (priv->revoked != revoked) {
>> dma_resv_lock(priv->dmabuf->resv, NULL);
>> priv->revoked = revoked;
>> dma_buf_move_notify(priv->dmabuf);
>>
>> A dma_buf_move_notify() just triggers asynchronous invalidation of the mapping!
>>
>> You need to use dma_resv_wait() to wait for that to finish.
>
> We (VFIO and IOMMUFD) followed the same pattern used in
> amdgpu_bo_move_notify(), which also does not wait.
>
> I'll add wait here.
>
> Thanks
>
>>
>> dma_resv_unlock(priv->dmabuf->resv);
>> }
>> fput(priv->dmabuf->file);
>> }
>> }
>>
>> Regards,
>> Christian.
>>
>>
>>> +}
>>> +
>>> +static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
>>> +{
>>> + /* Do nothing */
>>> +}
>>> +
>>> static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
>>> struct dma_buf_attachment *attachment)
>>> {
>>> @@ -76,6 +90,8 @@ static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
>>> }
>>>
>>> static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
>>> + .pin = vfio_pci_dma_buf_pin,
>>> + .unpin = vfio_pci_dma_buf_unpin,
>>> .attach = vfio_pci_dma_buf_attach,
>>> .map_dma_buf = vfio_pci_dma_buf_map,
>>> .unmap_dma_buf = vfio_pci_dma_buf_unmap,
>>>
>>
^ permalink raw reply [flat|nested] 37+ messages in thread
* ✗ CI.checkpatch: warning for dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
` (3 preceding siblings ...)
2026-01-18 12:08 ` [PATCH v2 4/4] vfio: Add pinned interface to perform " Leon Romanovsky
@ 2026-01-18 12:21 ` Patchwork
2026-01-18 12:23 ` ✓ CI.KUnit: success " Patchwork
` (4 subsequent siblings)
9 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2026-01-18 12:21 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: intel-xe
== Series Details ==
Series: dma-buf: document revoke mechanism to invalidate shared buffers
URL : https://patchwork.freedesktop.org/series/160246/
State : warning
== Summary ==
+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
ee83616c430ce70bd254bd2774d143a5733c8666
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 50068a9a201ec5b5ce464c4316274270e0041b95
Author: Leon Romanovsky <leon@kernel.org>
Date: Sun Jan 18 14:08:48 2026 +0200
vfio: Add pinned interface to perform revoke semantics
DMABUF ->pin() interface is called when the DMABUF importer perform
its DMA mapping, so let's use this opportunity to check if DMABUF
exporter revoked its buffer or not.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
+ /mt/dim checkpatch 1956fa9bd80d606f7eb92e877680de38a4f6e8ef drm-intel
fcf666f915a5 dma-buf: Rename .move_notify() callback to a clearer identifier
398e529f69d9 dma-buf: Document revoke semantics
-:17: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#17:
dma_buf_pin() after the DMA‑buf is attached to verify the exporter’s support
total: 0 errors, 1 warnings, 0 checks, 25 lines checked
712ad7bad6cf iommufd: Require DMABUF revoke semantics
50068a9a201e vfio: Add pinned interface to perform revoke semantics
^ permalink raw reply [flat|nested] 37+ messages in thread* ✓ CI.KUnit: success for dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
` (4 preceding siblings ...)
2026-01-18 12:21 ` ✗ CI.checkpatch: warning for dma-buf: document revoke mechanism to invalidate shared buffers Patchwork
@ 2026-01-18 12:23 ` Patchwork
2026-01-18 12:38 ` ✗ CI.checksparse: warning " Patchwork
` (3 subsequent siblings)
9 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2026-01-18 12:23 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: intel-xe
== Series Details ==
Series: dma-buf: document revoke mechanism to invalidate shared buffers
URL : https://patchwork.freedesktop.org/series/160246/
State : success
== Summary ==
+ trap cleanup EXIT
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/xe/.kunitconfig
[12:21:59] Configuring KUnit Kernel ...
Generating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[12:22:03] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
[12:22:35] Starting KUnit Kernel (1/1)...
[12:22:35] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[12:22:35] ================== guc_buf (11 subtests) ===================
[12:22:35] [PASSED] test_smallest
[12:22:35] [PASSED] test_largest
[12:22:35] [PASSED] test_granular
[12:22:35] [PASSED] test_unique
[12:22:35] [PASSED] test_overlap
[12:22:35] [PASSED] test_reusable
[12:22:35] [PASSED] test_too_big
[12:22:35] [PASSED] test_flush
[12:22:35] [PASSED] test_lookup
[12:22:35] [PASSED] test_data
[12:22:35] [PASSED] test_class
[12:22:35] ===================== [PASSED] guc_buf =====================
[12:22:35] =================== guc_dbm (7 subtests) ===================
[12:22:35] [PASSED] test_empty
[12:22:35] [PASSED] test_default
[12:22:35] ======================== test_size ========================
[12:22:35] [PASSED] 4
[12:22:35] [PASSED] 8
[12:22:35] [PASSED] 32
[12:22:35] [PASSED] 256
[12:22:35] ==================== [PASSED] test_size ====================
[12:22:35] ======================= test_reuse ========================
[12:22:35] [PASSED] 4
[12:22:35] [PASSED] 8
[12:22:35] [PASSED] 32
[12:22:35] [PASSED] 256
[12:22:35] =================== [PASSED] test_reuse ====================
[12:22:35] =================== test_range_overlap ====================
[12:22:35] [PASSED] 4
[12:22:35] [PASSED] 8
[12:22:35] [PASSED] 32
[12:22:35] [PASSED] 256
[12:22:35] =============== [PASSED] test_range_overlap ================
[12:22:35] =================== test_range_compact ====================
[12:22:35] [PASSED] 4
[12:22:35] [PASSED] 8
[12:22:35] [PASSED] 32
[12:22:35] [PASSED] 256
[12:22:35] =============== [PASSED] test_range_compact ================
[12:22:35] ==================== test_range_spare =====================
[12:22:35] [PASSED] 4
[12:22:35] [PASSED] 8
[12:22:35] [PASSED] 32
[12:22:35] [PASSED] 256
[12:22:35] ================ [PASSED] test_range_spare =================
[12:22:35] ===================== [PASSED] guc_dbm =====================
[12:22:35] =================== guc_idm (6 subtests) ===================
[12:22:35] [PASSED] bad_init
[12:22:35] [PASSED] no_init
[12:22:35] [PASSED] init_fini
[12:22:35] [PASSED] check_used
[12:22:35] [PASSED] check_quota
[12:22:35] [PASSED] check_all
[12:22:35] ===================== [PASSED] guc_idm =====================
[12:22:35] ================== no_relay (3 subtests) ===================
[12:22:35] [PASSED] xe_drops_guc2pf_if_not_ready
[12:22:35] [PASSED] xe_drops_guc2vf_if_not_ready
[12:22:35] [PASSED] xe_rejects_send_if_not_ready
[12:22:35] ==================== [PASSED] no_relay =====================
[12:22:35] ================== pf_relay (14 subtests) ==================
[12:22:35] [PASSED] pf_rejects_guc2pf_too_short
[12:22:35] [PASSED] pf_rejects_guc2pf_too_long
[12:22:35] [PASSED] pf_rejects_guc2pf_no_payload
[12:22:35] [PASSED] pf_fails_no_payload
[12:22:35] [PASSED] pf_fails_bad_origin
[12:22:35] [PASSED] pf_fails_bad_type
[12:22:35] [PASSED] pf_txn_reports_error
[12:22:35] [PASSED] pf_txn_sends_pf2guc
[12:22:35] [PASSED] pf_sends_pf2guc
[12:22:35] [SKIPPED] pf_loopback_nop
[12:22:35] [SKIPPED] pf_loopback_echo
[12:22:35] [SKIPPED] pf_loopback_fail
[12:22:35] [SKIPPED] pf_loopback_busy
[12:22:35] [SKIPPED] pf_loopback_retry
[12:22:35] ==================== [PASSED] pf_relay =====================
[12:22:35] ================== vf_relay (3 subtests) ===================
[12:22:35] [PASSED] vf_rejects_guc2vf_too_short
[12:22:35] [PASSED] vf_rejects_guc2vf_too_long
[12:22:35] [PASSED] vf_rejects_guc2vf_no_payload
[12:22:35] ==================== [PASSED] vf_relay =====================
[12:22:35] ================ pf_gt_config (6 subtests) =================
[12:22:35] [PASSED] fair_contexts_1vf
[12:22:35] [PASSED] fair_doorbells_1vf
[12:22:35] [PASSED] fair_ggtt_1vf
[12:22:35] ====================== fair_contexts ======================
[12:22:35] [PASSED] 1 VF
[12:22:35] [PASSED] 2 VFs
[12:22:35] [PASSED] 3 VFs
[12:22:35] [PASSED] 4 VFs
[12:22:35] [PASSED] 5 VFs
[12:22:35] [PASSED] 6 VFs
[12:22:35] [PASSED] 7 VFs
[12:22:35] [PASSED] 8 VFs
[12:22:35] [PASSED] 9 VFs
[12:22:35] [PASSED] 10 VFs
[12:22:35] [PASSED] 11 VFs
[12:22:35] [PASSED] 12 VFs
[12:22:35] [PASSED] 13 VFs
[12:22:35] [PASSED] 14 VFs
[12:22:35] [PASSED] 15 VFs
[12:22:35] [PASSED] 16 VFs
[12:22:35] [PASSED] 17 VFs
[12:22:35] [PASSED] 18 VFs
[12:22:35] [PASSED] 19 VFs
[12:22:35] [PASSED] 20 VFs
[12:22:35] [PASSED] 21 VFs
[12:22:35] [PASSED] 22 VFs
[12:22:35] [PASSED] 23 VFs
[12:22:35] [PASSED] 24 VFs
[12:22:35] [PASSED] 25 VFs
[12:22:35] [PASSED] 26 VFs
[12:22:35] [PASSED] 27 VFs
[12:22:35] [PASSED] 28 VFs
[12:22:35] [PASSED] 29 VFs
[12:22:35] [PASSED] 30 VFs
[12:22:35] [PASSED] 31 VFs
[12:22:35] [PASSED] 32 VFs
[12:22:35] [PASSED] 33 VFs
[12:22:35] [PASSED] 34 VFs
[12:22:35] [PASSED] 35 VFs
[12:22:35] [PASSED] 36 VFs
[12:22:35] [PASSED] 37 VFs
[12:22:35] [PASSED] 38 VFs
[12:22:35] [PASSED] 39 VFs
[12:22:35] [PASSED] 40 VFs
[12:22:35] [PASSED] 41 VFs
[12:22:35] [PASSED] 42 VFs
[12:22:35] [PASSED] 43 VFs
[12:22:35] [PASSED] 44 VFs
[12:22:35] [PASSED] 45 VFs
[12:22:35] [PASSED] 46 VFs
[12:22:35] [PASSED] 47 VFs
[12:22:35] [PASSED] 48 VFs
[12:22:35] [PASSED] 49 VFs
[12:22:35] [PASSED] 50 VFs
[12:22:35] [PASSED] 51 VFs
[12:22:35] [PASSED] 52 VFs
[12:22:35] [PASSED] 53 VFs
[12:22:35] [PASSED] 54 VFs
[12:22:35] [PASSED] 55 VFs
[12:22:35] [PASSED] 56 VFs
[12:22:35] [PASSED] 57 VFs
[12:22:35] [PASSED] 58 VFs
[12:22:35] [PASSED] 59 VFs
[12:22:35] [PASSED] 60 VFs
[12:22:35] [PASSED] 61 VFs
[12:22:35] [PASSED] 62 VFs
[12:22:35] [PASSED] 63 VFs
[12:22:35] ================== [PASSED] fair_contexts ==================
[12:22:35] ===================== fair_doorbells ======================
[12:22:35] [PASSED] 1 VF
[12:22:35] [PASSED] 2 VFs
[12:22:35] [PASSED] 3 VFs
[12:22:35] [PASSED] 4 VFs
[12:22:35] [PASSED] 5 VFs
[12:22:35] [PASSED] 6 VFs
[12:22:35] [PASSED] 7 VFs
[12:22:35] [PASSED] 8 VFs
[12:22:35] [PASSED] 9 VFs
[12:22:35] [PASSED] 10 VFs
[12:22:35] [PASSED] 11 VFs
[12:22:35] [PASSED] 12 VFs
[12:22:35] [PASSED] 13 VFs
[12:22:35] [PASSED] 14 VFs
[12:22:35] [PASSED] 15 VFs
[12:22:35] [PASSED] 16 VFs
[12:22:35] [PASSED] 17 VFs
[12:22:35] [PASSED] 18 VFs
[12:22:35] [PASSED] 19 VFs
[12:22:35] [PASSED] 20 VFs
[12:22:35] [PASSED] 21 VFs
[12:22:35] [PASSED] 22 VFs
[12:22:35] [PASSED] 23 VFs
[12:22:35] [PASSED] 24 VFs
[12:22:35] [PASSED] 25 VFs
[12:22:35] [PASSED] 26 VFs
[12:22:35] [PASSED] 27 VFs
[12:22:35] [PASSED] 28 VFs
[12:22:35] [PASSED] 29 VFs
[12:22:35] [PASSED] 30 VFs
[12:22:35] [PASSED] 31 VFs
[12:22:35] [PASSED] 32 VFs
[12:22:35] [PASSED] 33 VFs
[12:22:35] [PASSED] 34 VFs
[12:22:35] [PASSED] 35 VFs
[12:22:35] [PASSED] 36 VFs
[12:22:35] [PASSED] 37 VFs
[12:22:35] [PASSED] 38 VFs
[12:22:35] [PASSED] 39 VFs
[12:22:35] [PASSED] 40 VFs
[12:22:35] [PASSED] 41 VFs
[12:22:35] [PASSED] 42 VFs
[12:22:35] [PASSED] 43 VFs
[12:22:35] [PASSED] 44 VFs
[12:22:35] [PASSED] 45 VFs
[12:22:35] [PASSED] 46 VFs
[12:22:35] [PASSED] 47 VFs
[12:22:35] [PASSED] 48 VFs
[12:22:35] [PASSED] 49 VFs
[12:22:35] [PASSED] 50 VFs
[12:22:35] [PASSED] 51 VFs
[12:22:35] [PASSED] 52 VFs
[12:22:35] [PASSED] 53 VFs
[12:22:35] [PASSED] 54 VFs
[12:22:35] [PASSED] 55 VFs
[12:22:35] [PASSED] 56 VFs
[12:22:35] [PASSED] 57 VFs
[12:22:35] [PASSED] 58 VFs
[12:22:35] [PASSED] 59 VFs
[12:22:35] [PASSED] 60 VFs
[12:22:35] [PASSED] 61 VFs
[12:22:35] [PASSED] 62 VFs
[12:22:35] [PASSED] 63 VFs
[12:22:35] ================= [PASSED] fair_doorbells ==================
[12:22:35] ======================== fair_ggtt ========================
[12:22:35] [PASSED] 1 VF
[12:22:35] [PASSED] 2 VFs
[12:22:35] [PASSED] 3 VFs
[12:22:35] [PASSED] 4 VFs
[12:22:35] [PASSED] 5 VFs
[12:22:35] [PASSED] 6 VFs
[12:22:35] [PASSED] 7 VFs
[12:22:35] [PASSED] 8 VFs
[12:22:35] [PASSED] 9 VFs
[12:22:35] [PASSED] 10 VFs
[12:22:35] [PASSED] 11 VFs
[12:22:35] [PASSED] 12 VFs
[12:22:35] [PASSED] 13 VFs
[12:22:35] [PASSED] 14 VFs
[12:22:35] [PASSED] 15 VFs
[12:22:35] [PASSED] 16 VFs
[12:22:35] [PASSED] 17 VFs
[12:22:35] [PASSED] 18 VFs
[12:22:35] [PASSED] 19 VFs
[12:22:35] [PASSED] 20 VFs
[12:22:35] [PASSED] 21 VFs
[12:22:35] [PASSED] 22 VFs
[12:22:35] [PASSED] 23 VFs
[12:22:35] [PASSED] 24 VFs
[12:22:35] [PASSED] 25 VFs
[12:22:35] [PASSED] 26 VFs
[12:22:35] [PASSED] 27 VFs
[12:22:35] [PASSED] 28 VFs
[12:22:35] [PASSED] 29 VFs
[12:22:35] [PASSED] 30 VFs
[12:22:35] [PASSED] 31 VFs
[12:22:35] [PASSED] 32 VFs
[12:22:35] [PASSED] 33 VFs
[12:22:35] [PASSED] 34 VFs
[12:22:35] [PASSED] 35 VFs
[12:22:35] [PASSED] 36 VFs
[12:22:35] [PASSED] 37 VFs
[12:22:35] [PASSED] 38 VFs
[12:22:35] [PASSED] 39 VFs
[12:22:35] [PASSED] 40 VFs
[12:22:35] [PASSED] 41 VFs
[12:22:35] [PASSED] 42 VFs
[12:22:35] [PASSED] 43 VFs
[12:22:35] [PASSED] 44 VFs
[12:22:35] [PASSED] 45 VFs
[12:22:35] [PASSED] 46 VFs
[12:22:35] [PASSED] 47 VFs
[12:22:35] [PASSED] 48 VFs
[12:22:35] [PASSED] 49 VFs
[12:22:35] [PASSED] 50 VFs
[12:22:35] [PASSED] 51 VFs
[12:22:35] [PASSED] 52 VFs
[12:22:35] [PASSED] 53 VFs
[12:22:35] [PASSED] 54 VFs
[12:22:35] [PASSED] 55 VFs
[12:22:35] [PASSED] 56 VFs
[12:22:35] [PASSED] 57 VFs
[12:22:35] [PASSED] 58 VFs
[12:22:35] [PASSED] 59 VFs
[12:22:35] [PASSED] 60 VFs
[12:22:35] [PASSED] 61 VFs
[12:22:35] [PASSED] 62 VFs
[12:22:35] [PASSED] 63 VFs
[12:22:35] ==================== [PASSED] fair_ggtt ====================
[12:22:35] ================== [PASSED] pf_gt_config ===================
[12:22:35] ===================== lmtt (1 subtest) =====================
[12:22:35] ======================== test_ops =========================
[12:22:35] [PASSED] 2-level
[12:22:35] [PASSED] multi-level
[12:22:35] ==================== [PASSED] test_ops =====================
[12:22:35] ====================== [PASSED] lmtt =======================
[12:22:35] ================= pf_service (11 subtests) =================
[12:22:35] [PASSED] pf_negotiate_any
[12:22:35] [PASSED] pf_negotiate_base_match
[12:22:35] [PASSED] pf_negotiate_base_newer
[12:22:35] [PASSED] pf_negotiate_base_next
[12:22:35] [SKIPPED] pf_negotiate_base_older
[12:22:35] [PASSED] pf_negotiate_base_prev
[12:22:35] [PASSED] pf_negotiate_latest_match
[12:22:35] [PASSED] pf_negotiate_latest_newer
[12:22:35] [PASSED] pf_negotiate_latest_next
[12:22:35] [SKIPPED] pf_negotiate_latest_older
[12:22:35] [SKIPPED] pf_negotiate_latest_prev
[12:22:35] =================== [PASSED] pf_service ====================
[12:22:35] ================= xe_guc_g2g (2 subtests) ==================
[12:22:35] ============== xe_live_guc_g2g_kunit_default ==============
[12:22:35] ========= [SKIPPED] xe_live_guc_g2g_kunit_default ==========
[12:22:35] ============== xe_live_guc_g2g_kunit_allmem ===============
[12:22:35] ========== [SKIPPED] xe_live_guc_g2g_kunit_allmem ==========
[12:22:35] =================== [SKIPPED] xe_guc_g2g ===================
[12:22:35] =================== xe_mocs (2 subtests) ===================
[12:22:35] ================ xe_live_mocs_kernel_kunit ================
[12:22:35] =========== [SKIPPED] xe_live_mocs_kernel_kunit ============
[12:22:35] ================ xe_live_mocs_reset_kunit =================
[12:22:35] ============ [SKIPPED] xe_live_mocs_reset_kunit ============
[12:22:35] ==================== [SKIPPED] xe_mocs =====================
[12:22:35] ================= xe_migrate (2 subtests) ==================
[12:22:35] ================= xe_migrate_sanity_kunit =================
[12:22:35] ============ [SKIPPED] xe_migrate_sanity_kunit =============
[12:22:35] ================== xe_validate_ccs_kunit ==================
[12:22:35] ============= [SKIPPED] xe_validate_ccs_kunit ==============
[12:22:35] =================== [SKIPPED] xe_migrate ===================
[12:22:35] ================== xe_dma_buf (1 subtest) ==================
[12:22:35] ==================== xe_dma_buf_kunit =====================
[12:22:35] ================ [SKIPPED] xe_dma_buf_kunit ================
[12:22:35] =================== [SKIPPED] xe_dma_buf ===================
[12:22:35] ================= xe_bo_shrink (1 subtest) =================
[12:22:35] =================== xe_bo_shrink_kunit ====================
[12:22:35] =============== [SKIPPED] xe_bo_shrink_kunit ===============
[12:22:35] ================== [SKIPPED] xe_bo_shrink ==================
[12:22:35] ==================== xe_bo (2 subtests) ====================
[12:22:35] ================== xe_ccs_migrate_kunit ===================
[12:22:35] ============== [SKIPPED] xe_ccs_migrate_kunit ==============
[12:22:35] ==================== xe_bo_evict_kunit ====================
[12:22:35] =============== [SKIPPED] xe_bo_evict_kunit ================
[12:22:35] ===================== [SKIPPED] xe_bo ======================
[12:22:35] ==================== args (13 subtests) ====================
[12:22:35] [PASSED] count_args_test
[12:22:35] [PASSED] call_args_example
[12:22:35] [PASSED] call_args_test
[12:22:35] [PASSED] drop_first_arg_example
[12:22:35] [PASSED] drop_first_arg_test
[12:22:35] [PASSED] first_arg_example
[12:22:35] [PASSED] first_arg_test
[12:22:35] [PASSED] last_arg_example
[12:22:35] [PASSED] last_arg_test
[12:22:35] [PASSED] pick_arg_example
[12:22:35] [PASSED] if_args_example
[12:22:35] [PASSED] if_args_test
[12:22:35] [PASSED] sep_comma_example
[12:22:35] ====================== [PASSED] args =======================
[12:22:35] =================== xe_pci (3 subtests) ====================
[12:22:35] ==================== check_graphics_ip ====================
[12:22:35] [PASSED] 12.00 Xe_LP
[12:22:35] [PASSED] 12.10 Xe_LP+
[12:22:35] [PASSED] 12.55 Xe_HPG
[12:22:35] [PASSED] 12.60 Xe_HPC
[12:22:35] [PASSED] 12.70 Xe_LPG
[12:22:35] [PASSED] 12.71 Xe_LPG
[12:22:35] [PASSED] 12.74 Xe_LPG+
[12:22:35] [PASSED] 20.01 Xe2_HPG
[12:22:35] [PASSED] 20.02 Xe2_HPG
[12:22:35] [PASSED] 20.04 Xe2_LPG
[12:22:35] [PASSED] 30.00 Xe3_LPG
[12:22:35] [PASSED] 30.01 Xe3_LPG
[12:22:35] [PASSED] 30.03 Xe3_LPG
[12:22:35] [PASSED] 30.04 Xe3_LPG
[12:22:35] [PASSED] 30.05 Xe3_LPG
[12:22:35] [PASSED] 35.11 Xe3p_XPC
[12:22:35] ================ [PASSED] check_graphics_ip ================
[12:22:35] ===================== check_media_ip ======================
[12:22:35] [PASSED] 12.00 Xe_M
[12:22:35] [PASSED] 12.55 Xe_HPM
[12:22:35] [PASSED] 13.00 Xe_LPM+
[12:22:35] [PASSED] 13.01 Xe2_HPM
[12:22:35] [PASSED] 20.00 Xe2_LPM
[12:22:35] [PASSED] 30.00 Xe3_LPM
[12:22:35] [PASSED] 30.02 Xe3_LPM
[12:22:35] [PASSED] 35.00 Xe3p_LPM
[12:22:35] [PASSED] 35.03 Xe3p_HPM
[12:22:35] ================= [PASSED] check_media_ip ==================
[12:22:35] =================== check_platform_desc ===================
[12:22:35] [PASSED] 0x9A60 (TIGERLAKE)
[12:22:35] [PASSED] 0x9A68 (TIGERLAKE)
[12:22:35] [PASSED] 0x9A70 (TIGERLAKE)
[12:22:35] [PASSED] 0x9A40 (TIGERLAKE)
[12:22:35] [PASSED] 0x9A49 (TIGERLAKE)
[12:22:35] [PASSED] 0x9A59 (TIGERLAKE)
[12:22:35] [PASSED] 0x9A78 (TIGERLAKE)
[12:22:35] [PASSED] 0x9AC0 (TIGERLAKE)
[12:22:35] [PASSED] 0x9AC9 (TIGERLAKE)
[12:22:35] [PASSED] 0x9AD9 (TIGERLAKE)
[12:22:35] [PASSED] 0x9AF8 (TIGERLAKE)
[12:22:35] [PASSED] 0x4C80 (ROCKETLAKE)
[12:22:35] [PASSED] 0x4C8A (ROCKETLAKE)
[12:22:35] [PASSED] 0x4C8B (ROCKETLAKE)
[12:22:35] [PASSED] 0x4C8C (ROCKETLAKE)
[12:22:35] [PASSED] 0x4C90 (ROCKETLAKE)
[12:22:35] [PASSED] 0x4C9A (ROCKETLAKE)
[12:22:35] [PASSED] 0x4680 (ALDERLAKE_S)
[12:22:35] [PASSED] 0x4682 (ALDERLAKE_S)
[12:22:35] [PASSED] 0x4688 (ALDERLAKE_S)
[12:22:35] [PASSED] 0x468A (ALDERLAKE_S)
[12:22:35] [PASSED] 0x468B (ALDERLAKE_S)
[12:22:35] [PASSED] 0x4690 (ALDERLAKE_S)
[12:22:35] [PASSED] 0x4692 (ALDERLAKE_S)
[12:22:35] [PASSED] 0x4693 (ALDERLAKE_S)
[12:22:35] [PASSED] 0x46A0 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46A1 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46A2 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46A3 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46A6 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46A8 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46AA (ALDERLAKE_P)
[12:22:35] [PASSED] 0x462A (ALDERLAKE_P)
[12:22:35] [PASSED] 0x4626 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x4628 (ALDERLAKE_P)
stty: 'standard input': Inappropriate ioctl for device
[12:22:35] [PASSED] 0x46B0 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46B1 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46B2 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46B3 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46C0 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46C1 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46C2 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46C3 (ALDERLAKE_P)
[12:22:35] [PASSED] 0x46D0 (ALDERLAKE_N)
[12:22:35] [PASSED] 0x46D1 (ALDERLAKE_N)
[12:22:35] [PASSED] 0x46D2 (ALDERLAKE_N)
[12:22:35] [PASSED] 0x46D3 (ALDERLAKE_N)
[12:22:35] [PASSED] 0x46D4 (ALDERLAKE_N)
[12:22:35] [PASSED] 0xA721 (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA7A1 (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA7A9 (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA7AC (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA7AD (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA720 (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA7A0 (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA7A8 (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA7AA (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA7AB (ALDERLAKE_P)
[12:22:35] [PASSED] 0xA780 (ALDERLAKE_S)
[12:22:35] [PASSED] 0xA781 (ALDERLAKE_S)
[12:22:35] [PASSED] 0xA782 (ALDERLAKE_S)
[12:22:35] [PASSED] 0xA783 (ALDERLAKE_S)
[12:22:35] [PASSED] 0xA788 (ALDERLAKE_S)
[12:22:35] [PASSED] 0xA789 (ALDERLAKE_S)
[12:22:35] [PASSED] 0xA78A (ALDERLAKE_S)
[12:22:35] [PASSED] 0xA78B (ALDERLAKE_S)
[12:22:35] [PASSED] 0x4905 (DG1)
[12:22:35] [PASSED] 0x4906 (DG1)
[12:22:35] [PASSED] 0x4907 (DG1)
[12:22:35] [PASSED] 0x4908 (DG1)
[12:22:35] [PASSED] 0x4909 (DG1)
[12:22:35] [PASSED] 0x56C0 (DG2)
[12:22:35] [PASSED] 0x56C2 (DG2)
[12:22:35] [PASSED] 0x56C1 (DG2)
[12:22:35] [PASSED] 0x7D51 (METEORLAKE)
[12:22:35] [PASSED] 0x7DD1 (METEORLAKE)
[12:22:35] [PASSED] 0x7D41 (METEORLAKE)
[12:22:35] [PASSED] 0x7D67 (METEORLAKE)
[12:22:35] [PASSED] 0xB640 (METEORLAKE)
[12:22:35] [PASSED] 0x56A0 (DG2)
[12:22:35] [PASSED] 0x56A1 (DG2)
[12:22:35] [PASSED] 0x56A2 (DG2)
[12:22:35] [PASSED] 0x56BE (DG2)
[12:22:35] [PASSED] 0x56BF (DG2)
[12:22:35] [PASSED] 0x5690 (DG2)
[12:22:35] [PASSED] 0x5691 (DG2)
[12:22:35] [PASSED] 0x5692 (DG2)
[12:22:35] [PASSED] 0x56A5 (DG2)
[12:22:35] [PASSED] 0x56A6 (DG2)
[12:22:35] [PASSED] 0x56B0 (DG2)
[12:22:35] [PASSED] 0x56B1 (DG2)
[12:22:35] [PASSED] 0x56BA (DG2)
[12:22:35] [PASSED] 0x56BB (DG2)
[12:22:35] [PASSED] 0x56BC (DG2)
[12:22:35] [PASSED] 0x56BD (DG2)
[12:22:35] [PASSED] 0x5693 (DG2)
[12:22:35] [PASSED] 0x5694 (DG2)
[12:22:35] [PASSED] 0x5695 (DG2)
[12:22:35] [PASSED] 0x56A3 (DG2)
[12:22:35] [PASSED] 0x56A4 (DG2)
[12:22:35] [PASSED] 0x56B2 (DG2)
[12:22:35] [PASSED] 0x56B3 (DG2)
[12:22:35] [PASSED] 0x5696 (DG2)
[12:22:35] [PASSED] 0x5697 (DG2)
[12:22:35] [PASSED] 0xB69 (PVC)
[12:22:35] [PASSED] 0xB6E (PVC)
[12:22:35] [PASSED] 0xBD4 (PVC)
[12:22:35] [PASSED] 0xBD5 (PVC)
[12:22:35] [PASSED] 0xBD6 (PVC)
[12:22:35] [PASSED] 0xBD7 (PVC)
[12:22:35] [PASSED] 0xBD8 (PVC)
[12:22:35] [PASSED] 0xBD9 (PVC)
[12:22:35] [PASSED] 0xBDA (PVC)
[12:22:35] [PASSED] 0xBDB (PVC)
[12:22:35] [PASSED] 0xBE0 (PVC)
[12:22:35] [PASSED] 0xBE1 (PVC)
[12:22:35] [PASSED] 0xBE5 (PVC)
[12:22:35] [PASSED] 0x7D40 (METEORLAKE)
[12:22:35] [PASSED] 0x7D45 (METEORLAKE)
[12:22:35] [PASSED] 0x7D55 (METEORLAKE)
[12:22:35] [PASSED] 0x7D60 (METEORLAKE)
[12:22:35] [PASSED] 0x7DD5 (METEORLAKE)
[12:22:35] [PASSED] 0x6420 (LUNARLAKE)
[12:22:35] [PASSED] 0x64A0 (LUNARLAKE)
[12:22:35] [PASSED] 0x64B0 (LUNARLAKE)
[12:22:35] [PASSED] 0xE202 (BATTLEMAGE)
[12:22:35] [PASSED] 0xE209 (BATTLEMAGE)
[12:22:35] [PASSED] 0xE20B (BATTLEMAGE)
[12:22:35] [PASSED] 0xE20C (BATTLEMAGE)
[12:22:35] [PASSED] 0xE20D (BATTLEMAGE)
[12:22:35] [PASSED] 0xE210 (BATTLEMAGE)
[12:22:35] [PASSED] 0xE211 (BATTLEMAGE)
[12:22:35] [PASSED] 0xE212 (BATTLEMAGE)
[12:22:35] [PASSED] 0xE216 (BATTLEMAGE)
[12:22:35] [PASSED] 0xE220 (BATTLEMAGE)
[12:22:35] [PASSED] 0xE221 (BATTLEMAGE)
[12:22:35] [PASSED] 0xE222 (BATTLEMAGE)
[12:22:35] [PASSED] 0xE223 (BATTLEMAGE)
[12:22:35] [PASSED] 0xB080 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB081 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB082 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB083 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB084 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB085 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB086 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB087 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB08F (PANTHERLAKE)
[12:22:35] [PASSED] 0xB090 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB0A0 (PANTHERLAKE)
[12:22:35] [PASSED] 0xB0B0 (PANTHERLAKE)
[12:22:35] [PASSED] 0xFD80 (PANTHERLAKE)
[12:22:35] [PASSED] 0xFD81 (PANTHERLAKE)
[12:22:35] [PASSED] 0xD740 (NOVALAKE_S)
[12:22:35] [PASSED] 0xD741 (NOVALAKE_S)
[12:22:35] [PASSED] 0xD742 (NOVALAKE_S)
[12:22:35] [PASSED] 0xD743 (NOVALAKE_S)
[12:22:35] [PASSED] 0xD744 (NOVALAKE_S)
[12:22:35] [PASSED] 0xD745 (NOVALAKE_S)
[12:22:35] [PASSED] 0x674C (CRESCENTISLAND)
[12:22:35] =============== [PASSED] check_platform_desc ===============
[12:22:35] ===================== [PASSED] xe_pci ======================
[12:22:35] =================== xe_rtp (2 subtests) ====================
[12:22:35] =============== xe_rtp_process_to_sr_tests ================
[12:22:35] [PASSED] coalesce-same-reg
[12:22:35] [PASSED] no-match-no-add
[12:22:35] [PASSED] match-or
[12:22:35] [PASSED] match-or-xfail
[12:22:35] [PASSED] no-match-no-add-multiple-rules
[12:22:35] [PASSED] two-regs-two-entries
[12:22:35] [PASSED] clr-one-set-other
[12:22:35] [PASSED] set-field
[12:22:35] [PASSED] conflict-duplicate
[12:22:35] [PASSED] conflict-not-disjoint
[12:22:35] [PASSED] conflict-reg-type
[12:22:35] =========== [PASSED] xe_rtp_process_to_sr_tests ============
[12:22:35] ================== xe_rtp_process_tests ===================
[12:22:35] [PASSED] active1
[12:22:35] [PASSED] active2
[12:22:35] [PASSED] active-inactive
[12:22:35] [PASSED] inactive-active
[12:22:35] [PASSED] inactive-1st_or_active-inactive
[12:22:35] [PASSED] inactive-2nd_or_active-inactive
[12:22:35] [PASSED] inactive-last_or_active-inactive
[12:22:35] [PASSED] inactive-no_or_active-inactive
[12:22:35] ============== [PASSED] xe_rtp_process_tests ===============
[12:22:35] ===================== [PASSED] xe_rtp ======================
[12:22:35] ==================== xe_wa (1 subtest) =====================
[12:22:35] ======================== xe_wa_gt =========================
[12:22:35] [PASSED] TIGERLAKE B0
[12:22:35] [PASSED] DG1 A0
[12:22:35] [PASSED] DG1 B0
[12:22:35] [PASSED] ALDERLAKE_S A0
[12:22:35] [PASSED] ALDERLAKE_S B0
[12:22:35] [PASSED] ALDERLAKE_S C0
[12:22:35] [PASSED] ALDERLAKE_S D0
[12:22:35] [PASSED] ALDERLAKE_P A0
[12:22:35] [PASSED] ALDERLAKE_P B0
[12:22:35] [PASSED] ALDERLAKE_P C0
[12:22:35] [PASSED] ALDERLAKE_S RPLS D0
[12:22:35] [PASSED] ALDERLAKE_P RPLU E0
[12:22:35] [PASSED] DG2 G10 C0
[12:22:35] [PASSED] DG2 G11 B1
[12:22:35] [PASSED] DG2 G12 A1
[12:22:35] [PASSED] METEORLAKE 12.70(Xe_LPG) A0 13.00(Xe_LPM+) A0
[12:22:35] [PASSED] METEORLAKE 12.71(Xe_LPG) A0 13.00(Xe_LPM+) A0
[12:22:35] [PASSED] METEORLAKE 12.74(Xe_LPG+) A0 13.00(Xe_LPM+) A0
[12:22:35] [PASSED] LUNARLAKE 20.04(Xe2_LPG) A0 20.00(Xe2_LPM) A0
[12:22:35] [PASSED] LUNARLAKE 20.04(Xe2_LPG) B0 20.00(Xe2_LPM) A0
[12:22:35] [PASSED] BATTLEMAGE 20.01(Xe2_HPG) A0 13.01(Xe2_HPM) A1
[12:22:35] [PASSED] PANTHERLAKE 30.00(Xe3_LPG) A0 30.00(Xe3_LPM) A0
[12:22:35] ==================== [PASSED] xe_wa_gt =====================
[12:22:35] ====================== [PASSED] xe_wa ======================
[12:22:35] ============================================================
[12:22:35] Testing complete. Ran 512 tests: passed: 494, skipped: 18
[12:22:35] Elapsed time: 36.178s total, 4.165s configuring, 31.497s building, 0.469s running
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/tests/.kunitconfig
[12:22:35] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[12:22:37] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
[12:23:02] Starting KUnit Kernel (1/1)...
[12:23:02] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[12:23:02] ============ drm_test_pick_cmdline (2 subtests) ============
[12:23:02] [PASSED] drm_test_pick_cmdline_res_1920_1080_60
[12:23:02] =============== drm_test_pick_cmdline_named ===============
[12:23:02] [PASSED] NTSC
[12:23:02] [PASSED] NTSC-J
[12:23:02] [PASSED] PAL
[12:23:02] [PASSED] PAL-M
[12:23:02] =========== [PASSED] drm_test_pick_cmdline_named ===========
[12:23:02] ============== [PASSED] drm_test_pick_cmdline ==============
[12:23:02] == drm_test_atomic_get_connector_for_encoder (1 subtest) ===
[12:23:02] [PASSED] drm_test_drm_atomic_get_connector_for_encoder
[12:23:02] ==== [PASSED] drm_test_atomic_get_connector_for_encoder ====
[12:23:02] =========== drm_validate_clone_mode (2 subtests) ===========
[12:23:02] ============== drm_test_check_in_clone_mode ===============
[12:23:02] [PASSED] in_clone_mode
[12:23:02] [PASSED] not_in_clone_mode
[12:23:02] ========== [PASSED] drm_test_check_in_clone_mode ===========
[12:23:02] =============== drm_test_check_valid_clones ===============
[12:23:02] [PASSED] not_in_clone_mode
[12:23:02] [PASSED] valid_clone
[12:23:02] [PASSED] invalid_clone
[12:23:02] =========== [PASSED] drm_test_check_valid_clones ===========
[12:23:02] ============= [PASSED] drm_validate_clone_mode =============
[12:23:02] ============= drm_validate_modeset (1 subtest) =============
[12:23:02] [PASSED] drm_test_check_connector_changed_modeset
[12:23:02] ============== [PASSED] drm_validate_modeset ===============
[12:23:02] ====== drm_test_bridge_get_current_state (2 subtests) ======
[12:23:02] [PASSED] drm_test_drm_bridge_get_current_state_atomic
[12:23:02] [PASSED] drm_test_drm_bridge_get_current_state_legacy
[12:23:02] ======== [PASSED] drm_test_bridge_get_current_state ========
[12:23:02] ====== drm_test_bridge_helper_reset_crtc (3 subtests) ======
[12:23:02] [PASSED] drm_test_drm_bridge_helper_reset_crtc_atomic
[12:23:02] [PASSED] drm_test_drm_bridge_helper_reset_crtc_atomic_disabled
[12:23:02] [PASSED] drm_test_drm_bridge_helper_reset_crtc_legacy
[12:23:02] ======== [PASSED] drm_test_bridge_helper_reset_crtc ========
[12:23:02] ============== drm_bridge_alloc (2 subtests) ===============
[12:23:02] [PASSED] drm_test_drm_bridge_alloc_basic
[12:23:02] [PASSED] drm_test_drm_bridge_alloc_get_put
[12:23:02] ================ [PASSED] drm_bridge_alloc =================
[12:23:02] ================== drm_buddy (8 subtests) ==================
[12:23:02] [PASSED] drm_test_buddy_alloc_limit
[12:23:02] [PASSED] drm_test_buddy_alloc_optimistic
[12:23:02] [PASSED] drm_test_buddy_alloc_pessimistic
[12:23:02] [PASSED] drm_test_buddy_alloc_pathological
[12:23:02] [PASSED] drm_test_buddy_alloc_contiguous
[12:23:02] [PASSED] drm_test_buddy_alloc_clear
[12:23:02] [PASSED] drm_test_buddy_alloc_range_bias
[12:23:02] [PASSED] drm_test_buddy_fragmentation_performance
[12:23:02] ==================== [PASSED] drm_buddy ====================
[12:23:02] ============= drm_cmdline_parser (40 subtests) =============
[12:23:02] [PASSED] drm_test_cmdline_force_d_only
[12:23:02] [PASSED] drm_test_cmdline_force_D_only_dvi
[12:23:02] [PASSED] drm_test_cmdline_force_D_only_hdmi
[12:23:02] [PASSED] drm_test_cmdline_force_D_only_not_digital
[12:23:02] [PASSED] drm_test_cmdline_force_e_only
[12:23:02] [PASSED] drm_test_cmdline_res
[12:23:02] [PASSED] drm_test_cmdline_res_vesa
[12:23:02] [PASSED] drm_test_cmdline_res_vesa_rblank
[12:23:02] [PASSED] drm_test_cmdline_res_rblank
[12:23:02] [PASSED] drm_test_cmdline_res_bpp
[12:23:02] [PASSED] drm_test_cmdline_res_refresh
[12:23:02] [PASSED] drm_test_cmdline_res_bpp_refresh
[12:23:02] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced
[12:23:02] [PASSED] drm_test_cmdline_res_bpp_refresh_margins
[12:23:02] [PASSED] drm_test_cmdline_res_bpp_refresh_force_off
[12:23:02] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on
[12:23:02] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_analog
[12:23:02] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_digital
[12:23:02] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced_margins_force_on
[12:23:02] [PASSED] drm_test_cmdline_res_margins_force_on
[12:23:02] [PASSED] drm_test_cmdline_res_vesa_margins
[12:23:02] [PASSED] drm_test_cmdline_name
[12:23:02] [PASSED] drm_test_cmdline_name_bpp
[12:23:02] [PASSED] drm_test_cmdline_name_option
[12:23:02] [PASSED] drm_test_cmdline_name_bpp_option
[12:23:02] [PASSED] drm_test_cmdline_rotate_0
[12:23:02] [PASSED] drm_test_cmdline_rotate_90
[12:23:02] [PASSED] drm_test_cmdline_rotate_180
[12:23:02] [PASSED] drm_test_cmdline_rotate_270
[12:23:02] [PASSED] drm_test_cmdline_hmirror
[12:23:02] [PASSED] drm_test_cmdline_vmirror
[12:23:02] [PASSED] drm_test_cmdline_margin_options
[12:23:02] [PASSED] drm_test_cmdline_multiple_options
[12:23:02] [PASSED] drm_test_cmdline_bpp_extra_and_option
[12:23:02] [PASSED] drm_test_cmdline_extra_and_option
[12:23:02] [PASSED] drm_test_cmdline_freestanding_options
[12:23:02] [PASSED] drm_test_cmdline_freestanding_force_e_and_options
[12:23:02] [PASSED] drm_test_cmdline_panel_orientation
[12:23:02] ================ drm_test_cmdline_invalid =================
[12:23:02] [PASSED] margin_only
[12:23:02] [PASSED] interlace_only
[12:23:02] [PASSED] res_missing_x
[12:23:02] [PASSED] res_missing_y
[12:23:02] [PASSED] res_bad_y
[12:23:02] [PASSED] res_missing_y_bpp
[12:23:02] [PASSED] res_bad_bpp
[12:23:02] [PASSED] res_bad_refresh
[12:23:02] [PASSED] res_bpp_refresh_force_on_off
[12:23:02] [PASSED] res_invalid_mode
[12:23:02] [PASSED] res_bpp_wrong_place_mode
[12:23:02] [PASSED] name_bpp_refresh
[12:23:02] [PASSED] name_refresh
[12:23:02] [PASSED] name_refresh_wrong_mode
[12:23:02] [PASSED] name_refresh_invalid_mode
[12:23:02] [PASSED] rotate_multiple
[12:23:02] [PASSED] rotate_invalid_val
[12:23:02] [PASSED] rotate_truncated
[12:23:02] [PASSED] invalid_option
[12:23:02] [PASSED] invalid_tv_option
[12:23:02] [PASSED] truncated_tv_option
[12:23:02] ============ [PASSED] drm_test_cmdline_invalid =============
[12:23:02] =============== drm_test_cmdline_tv_options ===============
[12:23:02] [PASSED] NTSC
[12:23:02] [PASSED] NTSC_443
[12:23:02] [PASSED] NTSC_J
[12:23:02] [PASSED] PAL
[12:23:02] [PASSED] PAL_M
[12:23:02] [PASSED] PAL_N
[12:23:02] [PASSED] SECAM
[12:23:02] [PASSED] MONO_525
[12:23:02] [PASSED] MONO_625
[12:23:02] =========== [PASSED] drm_test_cmdline_tv_options ===========
[12:23:02] =============== [PASSED] drm_cmdline_parser ================
[12:23:02] ========== drmm_connector_hdmi_init (20 subtests) ==========
[12:23:02] [PASSED] drm_test_connector_hdmi_init_valid
[12:23:02] [PASSED] drm_test_connector_hdmi_init_bpc_8
[12:23:02] [PASSED] drm_test_connector_hdmi_init_bpc_10
[12:23:02] [PASSED] drm_test_connector_hdmi_init_bpc_12
[12:23:02] [PASSED] drm_test_connector_hdmi_init_bpc_invalid
[12:23:02] [PASSED] drm_test_connector_hdmi_init_bpc_null
[12:23:02] [PASSED] drm_test_connector_hdmi_init_formats_empty
[12:23:02] [PASSED] drm_test_connector_hdmi_init_formats_no_rgb
[12:23:02] === drm_test_connector_hdmi_init_formats_yuv420_allowed ===
[12:23:02] [PASSED] supported_formats=0x9 yuv420_allowed=1
[12:23:02] [PASSED] supported_formats=0x9 yuv420_allowed=0
[12:23:02] [PASSED] supported_formats=0x3 yuv420_allowed=1
[12:23:02] [PASSED] supported_formats=0x3 yuv420_allowed=0
[12:23:02] === [PASSED] drm_test_connector_hdmi_init_formats_yuv420_allowed ===
[12:23:02] [PASSED] drm_test_connector_hdmi_init_null_ddc
[12:23:02] [PASSED] drm_test_connector_hdmi_init_null_product
[12:23:02] [PASSED] drm_test_connector_hdmi_init_null_vendor
[12:23:02] [PASSED] drm_test_connector_hdmi_init_product_length_exact
[12:23:02] [PASSED] drm_test_connector_hdmi_init_product_length_too_long
[12:23:02] [PASSED] drm_test_connector_hdmi_init_product_valid
[12:23:02] [PASSED] drm_test_connector_hdmi_init_vendor_length_exact
[12:23:02] [PASSED] drm_test_connector_hdmi_init_vendor_length_too_long
[12:23:02] [PASSED] drm_test_connector_hdmi_init_vendor_valid
[12:23:02] ========= drm_test_connector_hdmi_init_type_valid =========
[12:23:02] [PASSED] HDMI-A
[12:23:02] [PASSED] HDMI-B
[12:23:02] ===== [PASSED] drm_test_connector_hdmi_init_type_valid =====
[12:23:02] ======== drm_test_connector_hdmi_init_type_invalid ========
[12:23:02] [PASSED] Unknown
[12:23:02] [PASSED] VGA
[12:23:02] [PASSED] DVI-I
[12:23:02] [PASSED] DVI-D
[12:23:02] [PASSED] DVI-A
[12:23:02] [PASSED] Composite
[12:23:02] [PASSED] SVIDEO
[12:23:02] [PASSED] LVDS
[12:23:02] [PASSED] Component
[12:23:02] [PASSED] DIN
[12:23:02] [PASSED] DP
[12:23:02] [PASSED] TV
[12:23:02] [PASSED] eDP
[12:23:02] [PASSED] Virtual
[12:23:02] [PASSED] DSI
[12:23:02] [PASSED] DPI
[12:23:02] [PASSED] Writeback
[12:23:02] [PASSED] SPI
[12:23:02] [PASSED] USB
[12:23:02] ==== [PASSED] drm_test_connector_hdmi_init_type_invalid ====
[12:23:02] ============ [PASSED] drmm_connector_hdmi_init =============
[12:23:02] ============= drmm_connector_init (3 subtests) =============
[12:23:02] [PASSED] drm_test_drmm_connector_init
[12:23:02] [PASSED] drm_test_drmm_connector_init_null_ddc
[12:23:02] ========= drm_test_drmm_connector_init_type_valid =========
[12:23:02] [PASSED] Unknown
[12:23:02] [PASSED] VGA
[12:23:02] [PASSED] DVI-I
[12:23:02] [PASSED] DVI-D
[12:23:02] [PASSED] DVI-A
[12:23:02] [PASSED] Composite
[12:23:02] [PASSED] SVIDEO
[12:23:02] [PASSED] LVDS
[12:23:02] [PASSED] Component
[12:23:02] [PASSED] DIN
[12:23:02] [PASSED] DP
[12:23:02] [PASSED] HDMI-A
[12:23:02] [PASSED] HDMI-B
[12:23:02] [PASSED] TV
[12:23:02] [PASSED] eDP
[12:23:02] [PASSED] Virtual
[12:23:02] [PASSED] DSI
[12:23:02] [PASSED] DPI
[12:23:02] [PASSED] Writeback
[12:23:02] [PASSED] SPI
[12:23:02] [PASSED] USB
[12:23:02] ===== [PASSED] drm_test_drmm_connector_init_type_valid =====
[12:23:02] =============== [PASSED] drmm_connector_init ===============
[12:23:02] ========= drm_connector_dynamic_init (6 subtests) ==========
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_init
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_init_null_ddc
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_init_not_added
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_init_properties
[12:23:02] ===== drm_test_drm_connector_dynamic_init_type_valid ======
[12:23:02] [PASSED] Unknown
[12:23:02] [PASSED] VGA
[12:23:02] [PASSED] DVI-I
[12:23:02] [PASSED] DVI-D
[12:23:02] [PASSED] DVI-A
[12:23:02] [PASSED] Composite
[12:23:02] [PASSED] SVIDEO
[12:23:02] [PASSED] LVDS
[12:23:02] [PASSED] Component
[12:23:02] [PASSED] DIN
[12:23:02] [PASSED] DP
[12:23:02] [PASSED] HDMI-A
[12:23:02] [PASSED] HDMI-B
[12:23:02] [PASSED] TV
[12:23:02] [PASSED] eDP
[12:23:02] [PASSED] Virtual
[12:23:02] [PASSED] DSI
[12:23:02] [PASSED] DPI
[12:23:02] [PASSED] Writeback
[12:23:02] [PASSED] SPI
[12:23:02] [PASSED] USB
[12:23:02] = [PASSED] drm_test_drm_connector_dynamic_init_type_valid ==
[12:23:02] ======== drm_test_drm_connector_dynamic_init_name =========
[12:23:02] [PASSED] Unknown
[12:23:02] [PASSED] VGA
[12:23:02] [PASSED] DVI-I
[12:23:02] [PASSED] DVI-D
[12:23:02] [PASSED] DVI-A
[12:23:02] [PASSED] Composite
[12:23:02] [PASSED] SVIDEO
[12:23:02] [PASSED] LVDS
[12:23:02] [PASSED] Component
[12:23:02] [PASSED] DIN
[12:23:02] [PASSED] DP
[12:23:02] [PASSED] HDMI-A
[12:23:02] [PASSED] HDMI-B
[12:23:02] [PASSED] TV
[12:23:02] [PASSED] eDP
[12:23:02] [PASSED] Virtual
[12:23:02] [PASSED] DSI
[12:23:02] [PASSED] DPI
[12:23:02] [PASSED] Writeback
[12:23:02] [PASSED] SPI
[12:23:02] [PASSED] USB
[12:23:02] ==== [PASSED] drm_test_drm_connector_dynamic_init_name =====
[12:23:02] =========== [PASSED] drm_connector_dynamic_init ============
[12:23:02] ==== drm_connector_dynamic_register_early (4 subtests) =====
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_early_on_list
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_early_defer
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_early_no_init
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_early_no_mode_object
[12:23:02] ====== [PASSED] drm_connector_dynamic_register_early =======
[12:23:02] ======= drm_connector_dynamic_register (7 subtests) ========
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_on_list
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_no_defer
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_no_init
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_mode_object
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_sysfs
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_sysfs_name
[12:23:02] [PASSED] drm_test_drm_connector_dynamic_register_debugfs
[12:23:02] ========= [PASSED] drm_connector_dynamic_register ==========
[12:23:02] = drm_connector_attach_broadcast_rgb_property (2 subtests) =
[12:23:02] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property
[12:23:02] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector
[12:23:02] === [PASSED] drm_connector_attach_broadcast_rgb_property ===
[12:23:02] ========== drm_get_tv_mode_from_name (2 subtests) ==========
[12:23:02] ========== drm_test_get_tv_mode_from_name_valid ===========
[12:23:02] [PASSED] NTSC
[12:23:02] [PASSED] NTSC-443
[12:23:02] [PASSED] NTSC-J
[12:23:02] [PASSED] PAL
[12:23:02] [PASSED] PAL-M
[12:23:02] [PASSED] PAL-N
[12:23:02] [PASSED] SECAM
[12:23:02] [PASSED] Mono
[12:23:02] ====== [PASSED] drm_test_get_tv_mode_from_name_valid =======
[12:23:02] [PASSED] drm_test_get_tv_mode_from_name_truncated
[12:23:02] ============ [PASSED] drm_get_tv_mode_from_name ============
[12:23:02] = drm_test_connector_hdmi_compute_mode_clock (12 subtests) =
[12:23:02] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb
[12:23:02] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc
[12:23:02] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc_vic_1
[12:23:02] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc
[12:23:02] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc_vic_1
[12:23:02] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_double
[12:23:02] = drm_test_connector_hdmi_compute_mode_clock_yuv420_valid =
[12:23:02] [PASSED] VIC 96
[12:23:02] [PASSED] VIC 97
[12:23:02] [PASSED] VIC 101
[12:23:02] [PASSED] VIC 102
[12:23:02] [PASSED] VIC 106
[12:23:02] [PASSED] VIC 107
[12:23:02] === [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_valid ===
[12:23:02] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_10_bpc
[12:23:02] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_12_bpc
[12:23:02] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_8_bpc
[12:23:02] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_10_bpc
[12:23:02] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_12_bpc
[12:23:02] === [PASSED] drm_test_connector_hdmi_compute_mode_clock ====
[12:23:02] == drm_hdmi_connector_get_broadcast_rgb_name (2 subtests) ==
[12:23:02] === drm_test_drm_hdmi_connector_get_broadcast_rgb_name ====
[12:23:02] [PASSED] Automatic
[12:23:02] [PASSED] Full
[12:23:02] [PASSED] Limited 16:235
[12:23:02] === [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name ===
[12:23:02] [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name_invalid
[12:23:02] ==== [PASSED] drm_hdmi_connector_get_broadcast_rgb_name ====
[12:23:02] == drm_hdmi_connector_get_output_format_name (2 subtests) ==
[12:23:02] === drm_test_drm_hdmi_connector_get_output_format_name ====
[12:23:02] [PASSED] RGB
[12:23:02] [PASSED] YUV 4:2:0
[12:23:02] [PASSED] YUV 4:2:2
[12:23:02] [PASSED] YUV 4:4:4
[12:23:02] === [PASSED] drm_test_drm_hdmi_connector_get_output_format_name ===
[12:23:02] [PASSED] drm_test_drm_hdmi_connector_get_output_format_name_invalid
[12:23:02] ==== [PASSED] drm_hdmi_connector_get_output_format_name ====
[12:23:02] ============= drm_damage_helper (21 subtests) ==============
[12:23:02] [PASSED] drm_test_damage_iter_no_damage
[12:23:02] [PASSED] drm_test_damage_iter_no_damage_fractional_src
[12:23:02] [PASSED] drm_test_damage_iter_no_damage_src_moved
[12:23:02] [PASSED] drm_test_damage_iter_no_damage_fractional_src_moved
[12:23:02] [PASSED] drm_test_damage_iter_no_damage_not_visible
[12:23:02] [PASSED] drm_test_damage_iter_no_damage_no_crtc
[12:23:02] [PASSED] drm_test_damage_iter_no_damage_no_fb
[12:23:02] [PASSED] drm_test_damage_iter_simple_damage
[12:23:02] [PASSED] drm_test_damage_iter_single_damage
[12:23:02] [PASSED] drm_test_damage_iter_single_damage_intersect_src
[12:23:02] [PASSED] drm_test_damage_iter_single_damage_outside_src
[12:23:02] [PASSED] drm_test_damage_iter_single_damage_fractional_src
[12:23:02] [PASSED] drm_test_damage_iter_single_damage_intersect_fractional_src
[12:23:02] [PASSED] drm_test_damage_iter_single_damage_outside_fractional_src
[12:23:02] [PASSED] drm_test_damage_iter_single_damage_src_moved
[12:23:02] [PASSED] drm_test_damage_iter_single_damage_fractional_src_moved
[12:23:02] [PASSED] drm_test_damage_iter_damage
[12:23:02] [PASSED] drm_test_damage_iter_damage_one_intersect
[12:23:02] [PASSED] drm_test_damage_iter_damage_one_outside
[12:23:02] [PASSED] drm_test_damage_iter_damage_src_moved
[12:23:02] [PASSED] drm_test_damage_iter_damage_not_visible
[12:23:02] ================ [PASSED] drm_damage_helper ================
[12:23:02] ============== drm_dp_mst_helper (3 subtests) ==============
[12:23:02] ============== drm_test_dp_mst_calc_pbn_mode ==============
[12:23:02] [PASSED] Clock 154000 BPP 30 DSC disabled
[12:23:02] [PASSED] Clock 234000 BPP 30 DSC disabled
[12:23:02] [PASSED] Clock 297000 BPP 24 DSC disabled
[12:23:02] [PASSED] Clock 332880 BPP 24 DSC enabled
[12:23:02] [PASSED] Clock 324540 BPP 24 DSC enabled
[12:23:02] ========== [PASSED] drm_test_dp_mst_calc_pbn_mode ==========
[12:23:02] ============== drm_test_dp_mst_calc_pbn_div ===============
[12:23:02] [PASSED] Link rate 2000000 lane count 4
[12:23:02] [PASSED] Link rate 2000000 lane count 2
[12:23:02] [PASSED] Link rate 2000000 lane count 1
[12:23:02] [PASSED] Link rate 1350000 lane count 4
[12:23:02] [PASSED] Link rate 1350000 lane count 2
[12:23:02] [PASSED] Link rate 1350000 lane count 1
[12:23:02] [PASSED] Link rate 1000000 lane count 4
[12:23:02] [PASSED] Link rate 1000000 lane count 2
[12:23:02] [PASSED] Link rate 1000000 lane count 1
[12:23:02] [PASSED] Link rate 810000 lane count 4
[12:23:02] [PASSED] Link rate 810000 lane count 2
[12:23:02] [PASSED] Link rate 810000 lane count 1
[12:23:02] [PASSED] Link rate 540000 lane count 4
[12:23:02] [PASSED] Link rate 540000 lane count 2
[12:23:02] [PASSED] Link rate 540000 lane count 1
[12:23:02] [PASSED] Link rate 270000 lane count 4
[12:23:02] [PASSED] Link rate 270000 lane count 2
[12:23:02] [PASSED] Link rate 270000 lane count 1
[12:23:02] [PASSED] Link rate 162000 lane count 4
[12:23:02] [PASSED] Link rate 162000 lane count 2
[12:23:02] [PASSED] Link rate 162000 lane count 1
[12:23:02] ========== [PASSED] drm_test_dp_mst_calc_pbn_div ===========
[12:23:02] ========= drm_test_dp_mst_sideband_msg_req_decode =========
[12:23:02] [PASSED] DP_ENUM_PATH_RESOURCES with port number
[12:23:02] [PASSED] DP_POWER_UP_PHY with port number
[12:23:02] [PASSED] DP_POWER_DOWN_PHY with port number
[12:23:02] [PASSED] DP_ALLOCATE_PAYLOAD with SDP stream sinks
[12:23:02] [PASSED] DP_ALLOCATE_PAYLOAD with port number
[12:23:02] [PASSED] DP_ALLOCATE_PAYLOAD with VCPI
[12:23:02] [PASSED] DP_ALLOCATE_PAYLOAD with PBN
[12:23:02] [PASSED] DP_QUERY_PAYLOAD with port number
[12:23:02] [PASSED] DP_QUERY_PAYLOAD with VCPI
[12:23:02] [PASSED] DP_REMOTE_DPCD_READ with port number
[12:23:02] [PASSED] DP_REMOTE_DPCD_READ with DPCD address
[12:23:02] [PASSED] DP_REMOTE_DPCD_READ with max number of bytes
[12:23:02] [PASSED] DP_REMOTE_DPCD_WRITE with port number
[12:23:02] [PASSED] DP_REMOTE_DPCD_WRITE with DPCD address
[12:23:02] [PASSED] DP_REMOTE_DPCD_WRITE with data array
[12:23:02] [PASSED] DP_REMOTE_I2C_READ with port number
[12:23:02] [PASSED] DP_REMOTE_I2C_READ with I2C device ID
[12:23:02] [PASSED] DP_REMOTE_I2C_READ with transactions array
[12:23:02] [PASSED] DP_REMOTE_I2C_WRITE with port number
[12:23:02] [PASSED] DP_REMOTE_I2C_WRITE with I2C device ID
[12:23:02] [PASSED] DP_REMOTE_I2C_WRITE with data array
[12:23:02] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream ID
[12:23:02] [PASSED] DP_QUERY_STREAM_ENC_STATUS with client ID
[12:23:02] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream event
[12:23:02] [PASSED] DP_QUERY_STREAM_ENC_STATUS with valid stream event
[12:23:02] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream behavior
[12:23:02] [PASSED] DP_QUERY_STREAM_ENC_STATUS with a valid stream behavior
[12:23:02] ===== [PASSED] drm_test_dp_mst_sideband_msg_req_decode =====
[12:23:02] ================ [PASSED] drm_dp_mst_helper ================
[12:23:02] ================== drm_exec (7 subtests) ===================
[12:23:02] [PASSED] sanitycheck
[12:23:02] [PASSED] test_lock
[12:23:02] [PASSED] test_lock_unlock
[12:23:02] [PASSED] test_duplicates
[12:23:02] [PASSED] test_prepare
[12:23:02] [PASSED] test_prepare_array
[12:23:02] [PASSED] test_multiple_loops
[12:23:02] ==================== [PASSED] drm_exec =====================
[12:23:02] =========== drm_format_helper_test (17 subtests) ===========
[12:23:02] ============== drm_test_fb_xrgb8888_to_gray8 ==============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ========== [PASSED] drm_test_fb_xrgb8888_to_gray8 ==========
[12:23:02] ============= drm_test_fb_xrgb8888_to_rgb332 ==============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb332 ==========
[12:23:02] ============= drm_test_fb_xrgb8888_to_rgb565 ==============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb565 ==========
[12:23:02] ============ drm_test_fb_xrgb8888_to_xrgb1555 =============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ======== [PASSED] drm_test_fb_xrgb8888_to_xrgb1555 =========
[12:23:02] ============ drm_test_fb_xrgb8888_to_argb1555 =============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ======== [PASSED] drm_test_fb_xrgb8888_to_argb1555 =========
[12:23:02] ============ drm_test_fb_xrgb8888_to_rgba5551 =============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ======== [PASSED] drm_test_fb_xrgb8888_to_rgba5551 =========
[12:23:02] ============= drm_test_fb_xrgb8888_to_rgb888 ==============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb888 ==========
[12:23:02] ============= drm_test_fb_xrgb8888_to_bgr888 ==============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ========= [PASSED] drm_test_fb_xrgb8888_to_bgr888 ==========
[12:23:02] ============ drm_test_fb_xrgb8888_to_argb8888 =============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ======== [PASSED] drm_test_fb_xrgb8888_to_argb8888 =========
[12:23:02] =========== drm_test_fb_xrgb8888_to_xrgb2101010 ===========
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ======= [PASSED] drm_test_fb_xrgb8888_to_xrgb2101010 =======
[12:23:02] =========== drm_test_fb_xrgb8888_to_argb2101010 ===========
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ======= [PASSED] drm_test_fb_xrgb8888_to_argb2101010 =======
[12:23:02] ============== drm_test_fb_xrgb8888_to_mono ===============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ========== [PASSED] drm_test_fb_xrgb8888_to_mono ===========
[12:23:02] ==================== drm_test_fb_swab =====================
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ================ [PASSED] drm_test_fb_swab =================
[12:23:02] ============ drm_test_fb_xrgb8888_to_xbgr8888 =============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ======== [PASSED] drm_test_fb_xrgb8888_to_xbgr8888 =========
[12:23:02] ============ drm_test_fb_xrgb8888_to_abgr8888 =============
[12:23:02] [PASSED] single_pixel_source_buffer
[12:23:02] [PASSED] single_pixel_clip_rectangle
[12:23:02] [PASSED] well_known_colors
[12:23:02] [PASSED] destination_pitch
[12:23:02] ======== [PASSED] drm_test_fb_xrgb8888_to_abgr8888 =========
[12:23:02] ================= drm_test_fb_clip_offset =================
[12:23:02] [PASSED] pass through
[12:23:02] [PASSED] horizontal offset
[12:23:02] [PASSED] vertical offset
[12:23:02] [PASSED] horizontal and vertical offset
[12:23:02] [PASSED] horizontal offset (custom pitch)
[12:23:02] [PASSED] vertical offset (custom pitch)
[12:23:02] [PASSED] horizontal and vertical offset (custom pitch)
[12:23:02] ============= [PASSED] drm_test_fb_clip_offset =============
[12:23:02] =================== drm_test_fb_memcpy ====================
[12:23:02] [PASSED] single_pixel_source_buffer: XR24 little-endian (0x34325258)
[12:23:02] [PASSED] single_pixel_source_buffer: XRA8 little-endian (0x38415258)
[12:23:02] [PASSED] single_pixel_source_buffer: YU24 little-endian (0x34325559)
[12:23:02] [PASSED] single_pixel_clip_rectangle: XB24 little-endian (0x34324258)
[12:23:02] [PASSED] single_pixel_clip_rectangle: XRA8 little-endian (0x38415258)
[12:23:02] [PASSED] single_pixel_clip_rectangle: YU24 little-endian (0x34325559)
[12:23:02] [PASSED] well_known_colors: XB24 little-endian (0x34324258)
[12:23:02] [PASSED] well_known_colors: XRA8 little-endian (0x38415258)
[12:23:02] [PASSED] well_known_colors: YU24 little-endian (0x34325559)
[12:23:02] [PASSED] destination_pitch: XB24 little-endian (0x34324258)
[12:23:02] [PASSED] destination_pitch: XRA8 little-endian (0x38415258)
[12:23:02] [PASSED] destination_pitch: YU24 little-endian (0x34325559)
[12:23:02] =============== [PASSED] drm_test_fb_memcpy ================
[12:23:02] ============= [PASSED] drm_format_helper_test ==============
[12:23:02] ================= drm_format (18 subtests) =================
[12:23:02] [PASSED] drm_test_format_block_width_invalid
[12:23:02] [PASSED] drm_test_format_block_width_one_plane
[12:23:02] [PASSED] drm_test_format_block_width_two_plane
[12:23:02] [PASSED] drm_test_format_block_width_three_plane
[12:23:02] [PASSED] drm_test_format_block_width_tiled
[12:23:02] [PASSED] drm_test_format_block_height_invalid
[12:23:02] [PASSED] drm_test_format_block_height_one_plane
[12:23:02] [PASSED] drm_test_format_block_height_two_plane
[12:23:02] [PASSED] drm_test_format_block_height_three_plane
[12:23:02] [PASSED] drm_test_format_block_height_tiled
[12:23:02] [PASSED] drm_test_format_min_pitch_invalid
[12:23:02] [PASSED] drm_test_format_min_pitch_one_plane_8bpp
[12:23:02] [PASSED] drm_test_format_min_pitch_one_plane_16bpp
[12:23:02] [PASSED] drm_test_format_min_pitch_one_plane_24bpp
[12:23:02] [PASSED] drm_test_format_min_pitch_one_plane_32bpp
[12:23:02] [PASSED] drm_test_format_min_pitch_two_plane
[12:23:02] [PASSED] drm_test_format_min_pitch_three_plane_8bpp
[12:23:02] [PASSED] drm_test_format_min_pitch_tiled
[12:23:02] =================== [PASSED] drm_format ====================
[12:23:02] ============== drm_framebuffer (10 subtests) ===============
[12:23:02] ========== drm_test_framebuffer_check_src_coords ==========
[12:23:02] [PASSED] Success: source fits into fb
[12:23:02] [PASSED] Fail: overflowing fb with x-axis coordinate
[12:23:02] [PASSED] Fail: overflowing fb with y-axis coordinate
[12:23:02] [PASSED] Fail: overflowing fb with source width
[12:23:02] [PASSED] Fail: overflowing fb with source height
[12:23:02] ====== [PASSED] drm_test_framebuffer_check_src_coords ======
[12:23:02] [PASSED] drm_test_framebuffer_cleanup
[12:23:02] =============== drm_test_framebuffer_create ===============
[12:23:02] [PASSED] ABGR8888 normal sizes
[12:23:02] [PASSED] ABGR8888 max sizes
[12:23:02] [PASSED] ABGR8888 pitch greater than min required
[12:23:02] [PASSED] ABGR8888 pitch less than min required
[12:23:02] [PASSED] ABGR8888 Invalid width
[12:23:02] [PASSED] ABGR8888 Invalid buffer handle
[12:23:02] [PASSED] No pixel format
[12:23:02] [PASSED] ABGR8888 Width 0
[12:23:02] [PASSED] ABGR8888 Height 0
[12:23:02] [PASSED] ABGR8888 Out of bound height * pitch combination
[12:23:02] [PASSED] ABGR8888 Large buffer offset
[12:23:02] [PASSED] ABGR8888 Buffer offset for inexistent plane
[12:23:02] [PASSED] ABGR8888 Invalid flag
[12:23:02] [PASSED] ABGR8888 Set DRM_MODE_FB_MODIFIERS without modifiers
[12:23:02] [PASSED] ABGR8888 Valid buffer modifier
[12:23:02] [PASSED] ABGR8888 Invalid buffer modifier(DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
[12:23:02] [PASSED] ABGR8888 Extra pitches without DRM_MODE_FB_MODIFIERS
[12:23:02] [PASSED] ABGR8888 Extra pitches with DRM_MODE_FB_MODIFIERS
[12:23:02] [PASSED] NV12 Normal sizes
[12:23:02] [PASSED] NV12 Max sizes
[12:23:02] [PASSED] NV12 Invalid pitch
[12:23:02] [PASSED] NV12 Invalid modifier/missing DRM_MODE_FB_MODIFIERS flag
[12:23:02] [PASSED] NV12 different modifier per-plane
[12:23:02] [PASSED] NV12 with DRM_FORMAT_MOD_SAMSUNG_64_32_TILE
[12:23:02] [PASSED] NV12 Valid modifiers without DRM_MODE_FB_MODIFIERS
[12:23:02] [PASSED] NV12 Modifier for inexistent plane
[12:23:02] [PASSED] NV12 Handle for inexistent plane
[12:23:02] [PASSED] NV12 Handle for inexistent plane without DRM_MODE_FB_MODIFIERS
[12:23:02] [PASSED] YVU420 DRM_MODE_FB_MODIFIERS set without modifier
[12:23:02] [PASSED] YVU420 Normal sizes
[12:23:02] [PASSED] YVU420 Max sizes
[12:23:02] [PASSED] YVU420 Invalid pitch
[12:23:02] [PASSED] YVU420 Different pitches
[12:23:02] [PASSED] YVU420 Different buffer offsets/pitches
[12:23:02] [PASSED] YVU420 Modifier set just for plane 0, without DRM_MODE_FB_MODIFIERS
[12:23:02] [PASSED] YVU420 Modifier set just for planes 0, 1, without DRM_MODE_FB_MODIFIERS
[12:23:02] [PASSED] YVU420 Modifier set just for plane 0, 1, with DRM_MODE_FB_MODIFIERS
[12:23:02] [PASSED] YVU420 Valid modifier
[12:23:02] [PASSED] YVU420 Different modifiers per plane
[12:23:02] [PASSED] YVU420 Modifier for inexistent plane
[12:23:02] [PASSED] YUV420_10BIT Invalid modifier(DRM_FORMAT_MOD_LINEAR)
[12:23:02] [PASSED] X0L2 Normal sizes
[12:23:02] [PASSED] X0L2 Max sizes
[12:23:02] [PASSED] X0L2 Invalid pitch
[12:23:02] [PASSED] X0L2 Pitch greater than minimum required
[12:23:02] [PASSED] X0L2 Handle for inexistent plane
[12:23:02] [PASSED] X0L2 Offset for inexistent plane, without DRM_MODE_FB_MODIFIERS set
[12:23:02] [PASSED] X0L2 Modifier without DRM_MODE_FB_MODIFIERS set
[12:23:02] [PASSED] X0L2 Valid modifier
[12:23:02] [PASSED] X0L2 Modifier for inexistent plane
[12:23:02] =========== [PASSED] drm_test_framebuffer_create ===========
[12:23:02] [PASSED] drm_test_framebuffer_free
[12:23:02] [PASSED] drm_test_framebuffer_init
[12:23:02] [PASSED] drm_test_framebuffer_init_bad_format
[12:23:02] [PASSED] drm_test_framebuffer_init_dev_mismatch
[12:23:02] [PASSED] drm_test_framebuffer_lookup
[12:23:02] [PASSED] drm_test_framebuffer_lookup_inexistent
[12:23:02] [PASSED] drm_test_framebuffer_modifiers_not_supported
[12:23:02] ================= [PASSED] drm_framebuffer =================
[12:23:02] ================ drm_gem_shmem (8 subtests) ================
[12:23:02] [PASSED] drm_gem_shmem_test_obj_create
[12:23:02] [PASSED] drm_gem_shmem_test_obj_create_private
[12:23:02] [PASSED] drm_gem_shmem_test_pin_pages
[12:23:02] [PASSED] drm_gem_shmem_test_vmap
[12:23:02] [PASSED] drm_gem_shmem_test_get_sg_table
[12:23:02] [PASSED] drm_gem_shmem_test_get_pages_sgt
[12:23:02] [PASSED] drm_gem_shmem_test_madvise
[12:23:02] [PASSED] drm_gem_shmem_test_purge
[12:23:02] ================== [PASSED] drm_gem_shmem ==================
[12:23:02] === drm_atomic_helper_connector_hdmi_check (27 subtests) ===
[12:23:02] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode
[12:23:02] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode_vic_1
[12:23:02] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode
[12:23:02] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode_vic_1
[12:23:02] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode
[12:23:02] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode_vic_1
[12:23:02] ====== drm_test_check_broadcast_rgb_cea_mode_yuv420 =======
[12:23:02] [PASSED] Automatic
[12:23:02] [PASSED] Full
[12:23:02] [PASSED] Limited 16:235
[12:23:02] == [PASSED] drm_test_check_broadcast_rgb_cea_mode_yuv420 ===
[12:23:02] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_changed
[12:23:02] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_not_changed
[12:23:02] [PASSED] drm_test_check_disable_connector
[12:23:02] [PASSED] drm_test_check_hdmi_funcs_reject_rate
[12:23:02] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_rgb
[12:23:02] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_yuv420
[12:23:02] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_ignore_yuv422
[12:23:02] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_ignore_yuv420
[12:23:02] [PASSED] drm_test_check_driver_unsupported_fallback_yuv420
[12:23:02] [PASSED] drm_test_check_output_bpc_crtc_mode_changed
[12:23:02] [PASSED] drm_test_check_output_bpc_crtc_mode_not_changed
[12:23:02] [PASSED] drm_test_check_output_bpc_dvi
[12:23:02] [PASSED] drm_test_check_output_bpc_format_vic_1
[12:23:02] [PASSED] drm_test_check_output_bpc_format_display_8bpc_only
[12:23:02] [PASSED] drm_test_check_output_bpc_format_display_rgb_only
[12:23:02] [PASSED] drm_test_check_output_bpc_format_driver_8bpc_only
[12:23:02] [PASSED] drm_test_check_output_bpc_format_driver_rgb_only
[12:23:02] [PASSED] drm_test_check_tmds_char_rate_rgb_8bpc
[12:23:02] [PASSED] drm_test_check_tmds_char_rate_rgb_10bpc
[12:23:02] [PASSED] drm_test_check_tmds_char_rate_rgb_12bpc
[12:23:02] ===== [PASSED] drm_atomic_helper_connector_hdmi_check ======
[12:23:02] === drm_atomic_helper_connector_hdmi_reset (6 subtests) ====
[12:23:02] [PASSED] drm_test_check_broadcast_rgb_value
[12:23:02] [PASSED] drm_test_check_bpc_8_value
[12:23:02] [PASSED] drm_test_check_bpc_10_value
[12:23:02] [PASSED] drm_test_check_bpc_12_value
[12:23:02] [PASSED] drm_test_check_format_value
[12:23:02] [PASSED] drm_test_check_tmds_char_value
[12:23:02] ===== [PASSED] drm_atomic_helper_connector_hdmi_reset ======
[12:23:02] = drm_atomic_helper_connector_hdmi_mode_valid (4 subtests) =
[12:23:02] [PASSED] drm_test_check_mode_valid
[12:23:02] [PASSED] drm_test_check_mode_valid_reject
[12:23:02] [PASSED] drm_test_check_mode_valid_reject_rate
[12:23:02] [PASSED] drm_test_check_mode_valid_reject_max_clock
[12:23:02] === [PASSED] drm_atomic_helper_connector_hdmi_mode_valid ===
[12:23:02] ================= drm_managed (2 subtests) =================
[12:23:02] [PASSED] drm_test_managed_release_action
[12:23:02] [PASSED] drm_test_managed_run_action
[12:23:02] =================== [PASSED] drm_managed ===================
[12:23:02] =================== drm_mm (6 subtests) ====================
[12:23:02] [PASSED] drm_test_mm_init
[12:23:02] [PASSED] drm_test_mm_debug
[12:23:02] [PASSED] drm_test_mm_align32
[12:23:02] [PASSED] drm_test_mm_align64
[12:23:02] [PASSED] drm_test_mm_lowest
[12:23:02] [PASSED] drm_test_mm_highest
[12:23:02] ===================== [PASSED] drm_mm ======================
[12:23:02] ============= drm_modes_analog_tv (5 subtests) =============
[12:23:02] [PASSED] drm_test_modes_analog_tv_mono_576i
[12:23:02] [PASSED] drm_test_modes_analog_tv_ntsc_480i
[12:23:02] [PASSED] drm_test_modes_analog_tv_ntsc_480i_inlined
[12:23:02] [PASSED] drm_test_modes_analog_tv_pal_576i
[12:23:02] [PASSED] drm_test_modes_analog_tv_pal_576i_inlined
[12:23:02] =============== [PASSED] drm_modes_analog_tv ===============
[12:23:02] ============== drm_plane_helper (2 subtests) ===============
[12:23:02] =============== drm_test_check_plane_state ================
[12:23:02] [PASSED] clipping_simple
[12:23:02] [PASSED] clipping_rotate_reflect
[12:23:02] [PASSED] positioning_simple
[12:23:02] [PASSED] upscaling
[12:23:02] [PASSED] downscaling
[12:23:02] [PASSED] rounding1
[12:23:02] [PASSED] rounding2
[12:23:02] [PASSED] rounding3
[12:23:02] [PASSED] rounding4
[12:23:02] =========== [PASSED] drm_test_check_plane_state ============
[12:23:02] =========== drm_test_check_invalid_plane_state ============
[12:23:02] [PASSED] positioning_invalid
[12:23:02] [PASSED] upscaling_invalid
[12:23:02] [PASSED] downscaling_invalid
[12:23:02] ======= [PASSED] drm_test_check_invalid_plane_state ========
[12:23:02] ================ [PASSED] drm_plane_helper =================
[12:23:02] ====== drm_connector_helper_tv_get_modes (1 subtest) =======
[12:23:02] ====== drm_test_connector_helper_tv_get_modes_check =======
[12:23:02] [PASSED] None
[12:23:02] [PASSED] PAL
[12:23:02] [PASSED] NTSC
[12:23:02] [PASSED] Both, NTSC Default
[12:23:02] [PASSED] Both, PAL Default
[12:23:02] [PASSED] Both, NTSC Default, with PAL on command-line
[12:23:02] [PASSED] Both, PAL Default, with NTSC on command-line
[12:23:02] == [PASSED] drm_test_connector_helper_tv_get_modes_check ===
[12:23:02] ======== [PASSED] drm_connector_helper_tv_get_modes ========
[12:23:02] ================== drm_rect (9 subtests) ===================
[12:23:02] [PASSED] drm_test_rect_clip_scaled_div_by_zero
[12:23:02] [PASSED] drm_test_rect_clip_scaled_not_clipped
[12:23:02] [PASSED] drm_test_rect_clip_scaled_clipped
[12:23:02] [PASSED] drm_test_rect_clip_scaled_signed_vs_unsigned
[12:23:02] ================= drm_test_rect_intersect =================
[12:23:02] [PASSED] top-left x bottom-right: 2x2+1+1 x 2x2+0+0
[12:23:02] [PASSED] top-right x bottom-left: 2x2+0+0 x 2x2+1-1
[12:23:02] [PASSED] bottom-left x top-right: 2x2+1-1 x 2x2+0+0
[12:23:02] [PASSED] bottom-right x top-left: 2x2+0+0 x 2x2+1+1
[12:23:02] [PASSED] right x left: 2x1+0+0 x 3x1+1+0
[12:23:02] [PASSED] left x right: 3x1+1+0 x 2x1+0+0
[12:23:02] [PASSED] up x bottom: 1x2+0+0 x 1x3+0-1
[12:23:02] [PASSED] bottom x up: 1x3+0-1 x 1x2+0+0
[12:23:02] [PASSED] touching corner: 1x1+0+0 x 2x2+1+1
[12:23:02] [PASSED] touching side: 1x1+0+0 x 1x1+1+0
[12:23:02] [PASSED] equal rects: 2x2+0+0 x 2x2+0+0
[12:23:02] [PASSED] inside another: 2x2+0+0 x 1x1+1+1
[12:23:02] [PASSED] far away: 1x1+0+0 x 1x1+3+6
[12:23:02] [PASSED] points intersecting: 0x0+5+10 x 0x0+5+10
[12:23:02] [PASSED] points not intersecting: 0x0+0+0 x 0x0+5+10
[12:23:02] ============= [PASSED] drm_test_rect_intersect =============
[12:23:02] ================ drm_test_rect_calc_hscale ================
[12:23:02] [PASSED] normal use
[12:23:02] [PASSED] out of max range
[12:23:02] [PASSED] out of min range
[12:23:02] [PASSED] zero dst
[12:23:02] [PASSED] negative src
[12:23:02] [PASSED] negative dst
[12:23:02] ============ [PASSED] drm_test_rect_calc_hscale ============
[12:23:02] ================ drm_test_rect_calc_vscale ================
[12:23:02] [PASSED] normal use
stty: 'standard input': Inappropriate ioctl for device
[12:23:02] [PASSED] out of max range
[12:23:02] [PASSED] out of min range
[12:23:02] [PASSED] zero dst
[12:23:02] [PASSED] negative src
[12:23:02] [PASSED] negative dst
[12:23:02] ============ [PASSED] drm_test_rect_calc_vscale ============
[12:23:02] ================== drm_test_rect_rotate ===================
[12:23:02] [PASSED] reflect-x
[12:23:02] [PASSED] reflect-y
[12:23:02] [PASSED] rotate-0
[12:23:02] [PASSED] rotate-90
[12:23:02] [PASSED] rotate-180
[12:23:02] [PASSED] rotate-270
[12:23:02] ============== [PASSED] drm_test_rect_rotate ===============
[12:23:02] ================ drm_test_rect_rotate_inv =================
[12:23:02] [PASSED] reflect-x
[12:23:02] [PASSED] reflect-y
[12:23:02] [PASSED] rotate-0
[12:23:02] [PASSED] rotate-90
[12:23:02] [PASSED] rotate-180
[12:23:02] [PASSED] rotate-270
[12:23:02] ============ [PASSED] drm_test_rect_rotate_inv =============
[12:23:02] ==================== [PASSED] drm_rect =====================
[12:23:02] ============ drm_sysfb_modeset_test (1 subtest) ============
[12:23:02] ============ drm_test_sysfb_build_fourcc_list =============
[12:23:02] [PASSED] no native formats
[12:23:02] [PASSED] XRGB8888 as native format
[12:23:02] [PASSED] remove duplicates
[12:23:02] [PASSED] convert alpha formats
[12:23:02] [PASSED] random formats
[12:23:02] ======== [PASSED] drm_test_sysfb_build_fourcc_list =========
[12:23:02] ============= [PASSED] drm_sysfb_modeset_test ==============
[12:23:02] ================== drm_fixp (2 subtests) ===================
[12:23:02] [PASSED] drm_test_int2fixp
[12:23:02] [PASSED] drm_test_sm2fixp
[12:23:02] ==================== [PASSED] drm_fixp =====================
[12:23:02] ============================================================
[12:23:02] Testing complete. Ran 624 tests: passed: 624
[12:23:02] Elapsed time: 27.294s total, 1.707s configuring, 25.171s building, 0.361s running
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/ttm/tests/.kunitconfig
[12:23:03] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[12:23:04] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
[12:23:13] Starting KUnit Kernel (1/1)...
[12:23:13] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[12:23:14] ================= ttm_device (5 subtests) ==================
[12:23:14] [PASSED] ttm_device_init_basic
[12:23:14] [PASSED] ttm_device_init_multiple
[12:23:14] [PASSED] ttm_device_fini_basic
[12:23:14] [PASSED] ttm_device_init_no_vma_man
[12:23:14] ================== ttm_device_init_pools ==================
[12:23:14] [PASSED] No DMA allocations, no DMA32 required
[12:23:14] [PASSED] DMA allocations, DMA32 required
[12:23:14] [PASSED] No DMA allocations, DMA32 required
[12:23:14] [PASSED] DMA allocations, no DMA32 required
[12:23:14] ============== [PASSED] ttm_device_init_pools ==============
[12:23:14] =================== [PASSED] ttm_device ====================
[12:23:14] ================== ttm_pool (8 subtests) ===================
[12:23:14] ================== ttm_pool_alloc_basic ===================
[12:23:14] [PASSED] One page
[12:23:14] [PASSED] More than one page
[12:23:14] [PASSED] Above the allocation limit
[12:23:14] [PASSED] One page, with coherent DMA mappings enabled
[12:23:14] [PASSED] Above the allocation limit, with coherent DMA mappings enabled
[12:23:14] ============== [PASSED] ttm_pool_alloc_basic ===============
[12:23:14] ============== ttm_pool_alloc_basic_dma_addr ==============
[12:23:14] [PASSED] One page
[12:23:14] [PASSED] More than one page
[12:23:14] [PASSED] Above the allocation limit
[12:23:14] [PASSED] One page, with coherent DMA mappings enabled
[12:23:14] [PASSED] Above the allocation limit, with coherent DMA mappings enabled
[12:23:14] ========== [PASSED] ttm_pool_alloc_basic_dma_addr ==========
[12:23:14] [PASSED] ttm_pool_alloc_order_caching_match
[12:23:14] [PASSED] ttm_pool_alloc_caching_mismatch
[12:23:14] [PASSED] ttm_pool_alloc_order_mismatch
[12:23:14] [PASSED] ttm_pool_free_dma_alloc
[12:23:14] [PASSED] ttm_pool_free_no_dma_alloc
[12:23:14] [PASSED] ttm_pool_fini_basic
[12:23:14] ==================== [PASSED] ttm_pool =====================
[12:23:14] ================ ttm_resource (8 subtests) =================
[12:23:14] ================= ttm_resource_init_basic =================
[12:23:14] [PASSED] Init resource in TTM_PL_SYSTEM
[12:23:14] [PASSED] Init resource in TTM_PL_VRAM
[12:23:14] [PASSED] Init resource in a private placement
[12:23:14] [PASSED] Init resource in TTM_PL_SYSTEM, set placement flags
[12:23:14] ============= [PASSED] ttm_resource_init_basic =============
[12:23:14] [PASSED] ttm_resource_init_pinned
[12:23:14] [PASSED] ttm_resource_fini_basic
[12:23:14] [PASSED] ttm_resource_manager_init_basic
[12:23:14] [PASSED] ttm_resource_manager_usage_basic
[12:23:14] [PASSED] ttm_resource_manager_set_used_basic
[12:23:14] [PASSED] ttm_sys_man_alloc_basic
[12:23:14] [PASSED] ttm_sys_man_free_basic
[12:23:14] ================== [PASSED] ttm_resource ===================
[12:23:14] =================== ttm_tt (15 subtests) ===================
[12:23:14] ==================== ttm_tt_init_basic ====================
[12:23:14] [PASSED] Page-aligned size
[12:23:14] [PASSED] Extra pages requested
[12:23:14] ================ [PASSED] ttm_tt_init_basic ================
[12:23:14] [PASSED] ttm_tt_init_misaligned
[12:23:14] [PASSED] ttm_tt_fini_basic
[12:23:14] [PASSED] ttm_tt_fini_sg
[12:23:14] [PASSED] ttm_tt_fini_shmem
[12:23:14] [PASSED] ttm_tt_create_basic
[12:23:14] [PASSED] ttm_tt_create_invalid_bo_type
[12:23:14] [PASSED] ttm_tt_create_ttm_exists
[12:23:14] [PASSED] ttm_tt_create_failed
[12:23:14] [PASSED] ttm_tt_destroy_basic
[12:23:14] [PASSED] ttm_tt_populate_null_ttm
[12:23:14] [PASSED] ttm_tt_populate_populated_ttm
[12:23:14] [PASSED] ttm_tt_unpopulate_basic
[12:23:14] [PASSED] ttm_tt_unpopulate_empty_ttm
[12:23:14] [PASSED] ttm_tt_swapin_basic
[12:23:14] ===================== [PASSED] ttm_tt ======================
[12:23:14] =================== ttm_bo (14 subtests) ===================
[12:23:14] =========== ttm_bo_reserve_optimistic_no_ticket ===========
[12:23:14] [PASSED] Cannot be interrupted and sleeps
[12:23:14] [PASSED] Cannot be interrupted, locks straight away
[12:23:14] [PASSED] Can be interrupted, sleeps
[12:23:14] ======= [PASSED] ttm_bo_reserve_optimistic_no_ticket =======
[12:23:14] [PASSED] ttm_bo_reserve_locked_no_sleep
[12:23:14] [PASSED] ttm_bo_reserve_no_wait_ticket
[12:23:14] [PASSED] ttm_bo_reserve_double_resv
[12:23:14] [PASSED] ttm_bo_reserve_interrupted
[12:23:14] [PASSED] ttm_bo_reserve_deadlock
[12:23:14] [PASSED] ttm_bo_unreserve_basic
[12:23:14] [PASSED] ttm_bo_unreserve_pinned
[12:23:14] [PASSED] ttm_bo_unreserve_bulk
[12:23:14] [PASSED] ttm_bo_fini_basic
[12:23:14] [PASSED] ttm_bo_fini_shared_resv
[12:23:14] [PASSED] ttm_bo_pin_basic
[12:23:14] [PASSED] ttm_bo_pin_unpin_resource
[12:23:14] [PASSED] ttm_bo_multiple_pin_one_unpin
[12:23:14] ===================== [PASSED] ttm_bo ======================
[12:23:14] ============== ttm_bo_validate (21 subtests) ===============
[12:23:14] ============== ttm_bo_init_reserved_sys_man ===============
[12:23:14] [PASSED] Buffer object for userspace
[12:23:14] [PASSED] Kernel buffer object
[12:23:14] [PASSED] Shared buffer object
[12:23:14] ========== [PASSED] ttm_bo_init_reserved_sys_man ===========
[12:23:14] ============== ttm_bo_init_reserved_mock_man ==============
[12:23:14] [PASSED] Buffer object for userspace
[12:23:14] [PASSED] Kernel buffer object
[12:23:14] [PASSED] Shared buffer object
[12:23:14] ========== [PASSED] ttm_bo_init_reserved_mock_man ==========
[12:23:14] [PASSED] ttm_bo_init_reserved_resv
[12:23:14] ================== ttm_bo_validate_basic ==================
[12:23:14] [PASSED] Buffer object for userspace
[12:23:14] [PASSED] Kernel buffer object
[12:23:14] [PASSED] Shared buffer object
[12:23:14] ============== [PASSED] ttm_bo_validate_basic ==============
[12:23:14] [PASSED] ttm_bo_validate_invalid_placement
[12:23:14] ============= ttm_bo_validate_same_placement ==============
[12:23:14] [PASSED] System manager
[12:23:14] [PASSED] VRAM manager
[12:23:14] ========= [PASSED] ttm_bo_validate_same_placement ==========
[12:23:14] [PASSED] ttm_bo_validate_failed_alloc
[12:23:14] [PASSED] ttm_bo_validate_pinned
[12:23:14] [PASSED] ttm_bo_validate_busy_placement
[12:23:14] ================ ttm_bo_validate_multihop =================
[12:23:14] [PASSED] Buffer object for userspace
[12:23:14] [PASSED] Kernel buffer object
[12:23:14] [PASSED] Shared buffer object
[12:23:14] ============ [PASSED] ttm_bo_validate_multihop =============
[12:23:14] ========== ttm_bo_validate_no_placement_signaled ==========
[12:23:14] [PASSED] Buffer object in system domain, no page vector
[12:23:14] [PASSED] Buffer object in system domain with an existing page vector
[12:23:14] ====== [PASSED] ttm_bo_validate_no_placement_signaled ======
[12:23:14] ======== ttm_bo_validate_no_placement_not_signaled ========
[12:23:14] [PASSED] Buffer object for userspace
[12:23:14] [PASSED] Kernel buffer object
[12:23:14] [PASSED] Shared buffer object
[12:23:14] ==== [PASSED] ttm_bo_validate_no_placement_not_signaled ====
[12:23:14] [PASSED] ttm_bo_validate_move_fence_signaled
[12:23:14] ========= ttm_bo_validate_move_fence_not_signaled =========
[12:23:14] [PASSED] Waits for GPU
[12:23:14] [PASSED] Tries to lock straight away
[12:23:14] ===== [PASSED] ttm_bo_validate_move_fence_not_signaled =====
[12:23:14] [PASSED] ttm_bo_validate_happy_evict
[12:23:14] [PASSED] ttm_bo_validate_all_pinned_evict
[12:23:14] [PASSED] ttm_bo_validate_allowed_only_evict
[12:23:14] [PASSED] ttm_bo_validate_deleted_evict
[12:23:14] [PASSED] ttm_bo_validate_busy_domain_evict
[12:23:14] [PASSED] ttm_bo_validate_evict_gutting
[12:23:14] [PASSED] ttm_bo_validate_recrusive_evict
stty: 'standard input': Inappropriate ioctl for device
[12:23:14] ================= [PASSED] ttm_bo_validate =================
[12:23:14] ============================================================
[12:23:14] Testing complete. Ran 101 tests: passed: 101
[12:23:14] Elapsed time: 11.194s total, 1.675s configuring, 9.253s building, 0.226s running
+ cleanup
++ stat -c %u:%g /kernel
+ chown -R 1003:1003 /kernel
^ permalink raw reply [flat|nested] 37+ messages in thread* ✗ CI.checksparse: warning for dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
` (5 preceding siblings ...)
2026-01-18 12:23 ` ✓ CI.KUnit: success " Patchwork
@ 2026-01-18 12:38 ` Patchwork
2026-01-18 12:57 ` ✓ Xe.CI.BAT: success " Patchwork
` (2 subsequent siblings)
9 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2026-01-18 12:38 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: intel-xe
== Series Details ==
Series: dma-buf: document revoke mechanism to invalidate shared buffers
URL : https://patchwork.freedesktop.org/series/160246/
State : warning
== Summary ==
+ trap cleanup EXIT
+ KERNEL=/kernel
+ MT=/root/linux/maintainer-tools
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools /root/linux/maintainer-tools
Cloning into '/root/linux/maintainer-tools'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ make -C /root/linux/maintainer-tools
make: Entering directory '/root/linux/maintainer-tools'
cc -O2 -g -Wextra -o remap-log remap-log.c
make: Leaving directory '/root/linux/maintainer-tools'
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ /root/linux/maintainer-tools/dim sparse --fast 1956fa9bd80d606f7eb92e877680de38a4f6e8ef
Sparse version: 0.6.4 (Ubuntu: 0.6.4-4ubuntu3)
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/drm_bridge.c:1643:1: error: bad constant expression
+drivers/gpu/drm/drm_bridge.c:1644:1: error: bad constant expression
+drivers/gpu/drm/drm_bridge.c:1645:1: error: bad constant expression
+drivers/gpu/drm/drm_bridge.c:1645:1: error: bad constant expression
+drivers/gpu/drm/drm_gem_framebuffer_helper.c:23:1: error: bad constant expression
+drivers/gpu/drm/drm_gem_shmem_helper.c:28:1: error: bad constant expression
+drivers/gpu/drm/drm_gem_shmem_helper.c:967:1: error: bad constant expression
+drivers/gpu/drm/drm_gem_shmem_helper.c:968:1: error: bad constant expression
+drivers/gpu/drm/drm_gem_shmem_helper.c:969:1: error: bad constant expression
+drivers/gpu/drm/drm_gem_shmem_helper.c:969:1: error: bad constant expression
+drivers/gpu/drm/drm_prime.c:44:1: error: bad constant expression
+drivers/gpu/drm/i915/display/intel_display_debugfs.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/display/intel_dpt.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/display/intel_fb_bo.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/display/intel_fbc.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h, drivers/gpu/drm/i915/display/intel_display_trace.h):
+drivers/gpu/drm/i915/display/intel_fb.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/display/intel_fb_pin.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/display/intel_frontbuffer.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h, drivers/gpu/drm/i915/display/intel_display_trace.h):
+drivers/gpu/drm/i915/display/intel_overlay.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/display/intel_plane.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h, drivers/gpu/drm/i915/display/intel_display_trace.h):
+drivers/gpu/drm/i915/display/intel_psr.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:18:1: error: bad constant expression
+drivers/gpu/drm/i915/gem/i915_gem_pages.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/gt/intel_reset.c:1569:12: warning: context imbalance in '_intel_gt_reset_lock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_sseu.c:600:17: error: too long token expansion
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:191:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:192:1: error: bad constant expression
+drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:193:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_active.c:1062:16: warning: context imbalance in '__i915_active_fence_set' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_drm_client.c:92:9: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/i915/i915_drm_client.c:92:9: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/i915/i915_drm_client.c:92:9: expected struct list_head const *list
+drivers/gpu/drm/i915/i915_drm_client.c:92:9: got struct list_head [noderef] __rcu *pos
+drivers/gpu/drm/i915/i915_drm_client.c:92:9: struct list_head *
+drivers/gpu/drm/i915/i915_drm_client.c:92:9: struct list_head *
+drivers/gpu/drm/i915/i915_drm_client.c:92:9: struct list_head [noderef] __rcu *
+drivers/gpu/drm/i915/i915_drm_client.c:92:9: struct list_head [noderef] __rcu *
+drivers/gpu/drm/i915/i915_drm_client.c:92:9: warning: incorrect type in argument 1 (different address spaces)
+drivers/gpu/drm/i915/i915_initial_plane.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/i915_irq.c:467:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:467:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:475:16: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:475:16: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:480:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:480:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:480:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:518:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:518:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:526:16: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:526:16: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:531:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:531:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:531:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:575:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:575:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:578:15: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:578:15: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:582:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:582:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:589:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:589:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:589:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_irq.c:589:9: warning: unreplaced symbol '<noident>'
+drivers/gpu/drm/i915/i915_mitigations.c:133:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_module.c:125:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_module.c:126:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_module.c:128:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_module.c:129:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_module.c:129:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_panic.c: note: in included file (through drivers/gpu/drm/i915/display/intel_display_types.h):
+drivers/gpu/drm/i915/i915_params.c:100:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:100:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:104:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:104:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:107:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:107:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:110:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:110:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:119:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:119:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:123:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:123:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:125:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:125:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:66:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:66:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:69:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:69:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:73:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:73:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:79:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:79:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:84:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:84:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:88:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:88:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:91:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:91:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:95:1: error: bad constant expression
+drivers/gpu/drm/i915/i915_params.c:95:1: error: bad constant expression
+drivers/gpu/drm/i915/intel_uncore.c:1930:1: warning: context imbalance in 'fwtable_read8' - unexpected unlock
+drivers/gpu/drm/i915/intel_uncore.c:1931:1: warning: context imbalance in 'fwtable_read16' - unexpected unlock
+drivers/gpu/drm/i915/intel_uncore.c:1932:1: warning: context imbalance in 'fwtable_read32' - unexpected unlock
+drivers/gpu/drm/i915/intel_uncore.c:1933:1: warning: context imbalance in 'fwtable_read64' - unexpected unlock
+drivers/gpu/drm/i915/intel_uncore.c:1998:1: warning: context imbalance in 'gen6_write8' - unexpected unlock
+drivers/gpu/drm/i915/intel_uncore.c:1999:1: warning: context imbalance in 'gen6_write16' - unexpected unlock
+drivers/gpu/drm/i915/intel_uncore.c:2000:1: warning: context imbalance in 'gen6_write32' - unexpected unlock
+drivers/gpu/drm/i915/intel_uncore.c:2020:1: warning: context imbalance in 'fwtable_write8' - unexpected unlock
+drivers/gpu/drm/i915/intel_uncore.c:2021:1: warning: context imbalance in 'fwtable_write16' - unexpected unlock
+drivers/gpu/drm/i915/intel_uncore.c:2022:1: warning: context imbalance in 'fwtable_write32' - unexpected unlock
+drivers/gpu/drm/i915/intel_wakeref.c:148:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock
+drivers/gpu/drm/ttm/ttm_bo.c:1203:31: warning: symbol 'ttm_swap_ops' was not declared. Should it be static?
+drivers/gpu/drm/ttm/ttm_bo_util.c:329:38: expected void *virtual
+drivers/gpu/drm/ttm/ttm_bo_util.c:329:38: got void [noderef] __iomem *
+drivers/gpu/drm/ttm/ttm_bo_util.c:329:38: warning: incorrect type in assignment (different address spaces)
+drivers/gpu/drm/ttm/ttm_bo_util.c:332:38: expected void *virtual
+drivers/gpu/drm/ttm/ttm_bo_util.c:332:38: got void [noderef] __iomem *
+drivers/gpu/drm/ttm/ttm_bo_util.c:332:38: warning: incorrect type in assignment (different address spaces)
+drivers/gpu/drm/ttm/ttm_bo_util.c:335:38: expected void *virtual
+drivers/gpu/drm/ttm/ttm_bo_util.c:335:38: got void [noderef] __iomem *
+drivers/gpu/drm/ttm/ttm_bo_util.c:335:38: warning: incorrect type in assignment (different address spaces)
+drivers/gpu/drm/ttm/ttm_bo_util.c:465:28: expected void volatile [noderef] __iomem *addr
+drivers/gpu/drm/ttm/ttm_bo_util.c:465:28: got void *virtual
+drivers/gpu/drm/ttm/ttm_bo_util.c:465:28: warning: incorrect type in argument 1 (different address spaces)
+drivers/gpu/drm/ttm/ttm_pool.c:119:1: error: bad constant expression
+drivers/gpu/drm/ttm/ttm_pool.c:120:1: error: bad constant expression
+drivers/gpu/drm/ttm/ttm_tt.c:54:1: error: bad constant expression
+drivers/gpu/drm/ttm/ttm_tt.c:55:1: error: bad constant expression
+drivers/gpu/drm/ttm/ttm_tt.c:59:1: error: bad constant expression
+drivers/gpu/drm/ttm/ttm_tt.c:60:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_drv.c:217:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_drv.c:218:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_drv.c:218:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_drv.c:219:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_drv.c:220:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_drv.c:221:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_drv.c:52:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_drv.c:53:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_object.c:34:1: error: bad constant expression
+drivers/gpu/drm/virtio/virtgpu_prime.c:30:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+./include/linux/pwm.h:13:1: error: bad constant expression
+ cleanup
++ stat -c %u:%g /kernel
+ chown -R 1003:1003 /kernel
^ permalink raw reply [flat|nested] 37+ messages in thread* ✓ Xe.CI.BAT: success for dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
` (6 preceding siblings ...)
2026-01-18 12:38 ` ✗ CI.checksparse: warning " Patchwork
@ 2026-01-18 12:57 ` Patchwork
2026-01-18 14:06 ` ✗ Xe.CI.Full: failure " Patchwork
2026-01-18 14:16 ` [PATCH v2 0/4] " Thomas Hellström
9 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2026-01-18 12:57 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: intel-xe
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
== Series Details ==
Series: dma-buf: document revoke mechanism to invalidate shared buffers
URL : https://patchwork.freedesktop.org/series/160246/
State : success
== Summary ==
CI Bug Log - changes from xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef_BAT -> xe-pw-160246v1_BAT
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Participating hosts (12 -> 12)
------------------------------
No changes in participating hosts
Changes
-------
No changes found
Build changes
-------------
* Linux: xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef -> xe-pw-160246v1
IGT_8704: 8704
xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef: 1956fa9bd80d606f7eb92e877680de38a4f6e8ef
xe-pw-160246v1: 160246v1
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/index.html
[-- Attachment #2: Type: text/html, Size: 1434 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread* ✗ Xe.CI.Full: failure for dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
` (7 preceding siblings ...)
2026-01-18 12:57 ` ✓ Xe.CI.BAT: success " Patchwork
@ 2026-01-18 14:06 ` Patchwork
2026-01-18 14:16 ` [PATCH v2 0/4] " Thomas Hellström
9 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2026-01-18 14:06 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: intel-xe
[-- Attachment #1: Type: text/plain, Size: 9956 bytes --]
== Series Details ==
Series: dma-buf: document revoke mechanism to invalidate shared buffers
URL : https://patchwork.freedesktop.org/series/160246/
State : failure
== Summary ==
CI Bug Log - changes from xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef_FULL -> xe-pw-160246v1_FULL
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with xe-pw-160246v1_FULL absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in xe-pw-160246v1_FULL, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (2 -> 2)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in xe-pw-160246v1_FULL:
### IGT changes ###
#### Possible regressions ####
* igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-bmg: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-2/igt@kms_big_fb@x-tiled-64bpp-rotate-0.html
[2]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-2/igt@kms_big_fb@x-tiled-64bpp-rotate-0.html
Known issues
------------
Here are the changes found in xe-pw-160246v1_FULL that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@kms_atomic_transition@plane-all-modeset-transition-fencing:
- shard-bmg: [PASS][3] -> [DMESG-WARN][4] ([Intel XE#6766]) +1 other test dmesg-warn
[3]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-3/igt@kms_atomic_transition@plane-all-modeset-transition-fencing.html
[4]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-2/igt@kms_atomic_transition@plane-all-modeset-transition-fencing.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip:
- shard-bmg: [PASS][5] -> [ABORT][6] ([Intel XE#3970])
[5]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-3/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip.html
[6]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-2/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip.html
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-lnl: [PASS][7] -> [FAIL][8] ([Intel XE#1874])
[7]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-lnl-1/igt@kms_rotation_crc@multiplane-rotation-cropping-top.html
[8]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-lnl-4/igt@kms_rotation_crc@multiplane-rotation-cropping-top.html
* igt@xe_exec_store@basic-all@engine-drm_xe_engine_class_render-instance-0-tile-0:
- shard-lnl: [PASS][9] -> [DMESG-WARN][10] ([Intel XE#7063])
[9]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-lnl-2/igt@xe_exec_store@basic-all@engine-drm_xe_engine_class_render-instance-0-tile-0.html
[10]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-lnl-5/igt@xe_exec_store@basic-all@engine-drm_xe_engine_class_render-instance-0-tile-0.html
#### Possible fixes ####
* igt@kms_async_flips@async-flip-with-page-flip-events-linear-atomic@pipe-a-edp-1:
- shard-lnl: [FAIL][11] ([Intel XE#6054]) -> [PASS][12] +1 other test pass
[11]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-lnl-1/igt@kms_async_flips@async-flip-with-page-flip-events-linear-atomic@pipe-a-edp-1.html
[12]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-lnl-4/igt@kms_async_flips@async-flip-with-page-flip-events-linear-atomic@pipe-a-edp-1.html
* igt@kms_flip@flip-vs-expired-vblank@b-edp1:
- shard-lnl: [FAIL][13] ([Intel XE#301]) -> [PASS][14] +1 other test pass
[13]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-lnl-2/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html
[14]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-lnl-5/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html
* igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-bmg: [FAIL][15] -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-2/igt@kms_rotation_crc@multiplane-rotation-cropping-bottom.html
[16]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-10/igt@kms_rotation_crc@multiplane-rotation-cropping-bottom.html
* igt@xe_evict@evict-threads-large-multi-vm:
- shard-bmg: [SKIP][17] ([Intel XE#6703]) -> [PASS][18] +20 other tests pass
[17]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-2/igt@xe_evict@evict-threads-large-multi-vm.html
[18]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-10/igt@xe_evict@evict-threads-large-multi-vm.html
* igt@xe_exec_balancer@twice-cm-virtual-userptr-invalidate-race:
- shard-bmg: [DMESG-FAIL][19] ([Intel XE#5545] / [Intel XE#6652]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-2/igt@xe_exec_balancer@twice-cm-virtual-userptr-invalidate-race.html
[20]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-10/igt@xe_exec_balancer@twice-cm-virtual-userptr-invalidate-race.html
* igt@xe_exec_store@basic-all@engine-drm_xe_engine_class_video_decode-instance-0-tile-1:
- shard-lnl: [DMESG-WARN][21] ([Intel XE#7063]) -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-lnl-2/igt@xe_exec_store@basic-all@engine-drm_xe_engine_class_video_decode-instance-0-tile-1.html
[22]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-lnl-5/igt@xe_exec_store@basic-all@engine-drm_xe_engine_class_video_decode-instance-0-tile-1.html
* igt@xe_pm@s4-exec-after:
- shard-lnl: [DMESG-WARN][23] ([Intel XE#7024]) -> [PASS][24]
[23]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-lnl-5/igt@xe_pm@s4-exec-after.html
[24]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-lnl-3/igt@xe_pm@s4-exec-after.html
#### Warnings ####
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-shrfb-plflip-blt:
- shard-bmg: [SKIP][25] ([Intel XE#6703]) -> [SKIP][26] ([Intel XE#2313])
[25]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-2/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-shrfb-plflip-blt.html
[26]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-10/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-shrfb-plflip-blt.html
* igt@kms_tiled_display@basic-test-pattern-with-chamelium:
- shard-bmg: [SKIP][27] ([Intel XE#2426]) -> [SKIP][28] ([Intel XE#2509])
[27]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-9/igt@kms_tiled_display@basic-test-pattern-with-chamelium.html
[28]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-2/igt@kms_tiled_display@basic-test-pattern-with-chamelium.html
* igt@kms_vrr@max-min:
- shard-bmg: [SKIP][29] ([Intel XE#6703]) -> [SKIP][30] ([Intel XE#1499])
[29]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-2/igt@kms_vrr@max-min.html
[30]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-10/igt@kms_vrr@max-min.html
* igt@xe_exec_system_allocator@twice-large-mmap-new-huge-nomemset:
- shard-bmg: [SKIP][31] ([Intel XE#6703]) -> [SKIP][32] ([Intel XE#4943])
[31]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef/shard-bmg-2/igt@xe_exec_system_allocator@twice-large-mmap-new-huge-nomemset.html
[32]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/shard-bmg-10/igt@xe_exec_system_allocator@twice-large-mmap-new-huge-nomemset.html
[Intel XE#1499]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1499
[Intel XE#1874]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1874
[Intel XE#2313]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2313
[Intel XE#2426]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2426
[Intel XE#2509]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2509
[Intel XE#301]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/301
[Intel XE#3970]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3970
[Intel XE#4943]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4943
[Intel XE#5545]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5545
[Intel XE#6054]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6054
[Intel XE#6652]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6652
[Intel XE#6703]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6703
[Intel XE#6766]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6766
[Intel XE#7024]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7024
[Intel XE#7063]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7063
Build changes
-------------
* Linux: xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef -> xe-pw-160246v1
IGT_8704: 8704
xe-4400-1956fa9bd80d606f7eb92e877680de38a4f6e8ef: 1956fa9bd80d606f7eb92e877680de38a4f6e8ef
xe-pw-160246v1: 160246v1
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160246v1/index.html
[-- Attachment #2: Type: text/html, Size: 11164 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-18 12:08 [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers Leon Romanovsky
` (8 preceding siblings ...)
2026-01-18 14:06 ` ✗ Xe.CI.Full: failure " Patchwork
@ 2026-01-18 14:16 ` Thomas Hellström
2026-01-19 7:52 ` Leon Romanovsky
9 siblings, 1 reply; 37+ messages in thread
From: Thomas Hellström @ 2026-01-18 14:16 UTC (permalink / raw)
To: Leon Romanovsky, Sumit Semwal, Christian König, Alex Deucher,
David Airlie, Simona Vetter, Gerd Hoffmann, Dmitry Osipenko,
Gurchetan Singh, Chia-I Wu, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Lucas De Marchi, Rodrigo Vivi, Jason Gunthorpe,
Kevin Tian, Joerg Roedel, Will Deacon, Robin Murphy,
Alex Williamson
Cc: linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
Hi, Leon,
On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
> Changelog:
> v2:
> * Changed series to document the revoke semantics instead of
> implementing it.
> v1:
> https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com
>
> ---------------------------------------------------------------------
> ----
> This series documents a dma-buf “revoke” mechanism: to allow a dma-
> buf
> exporter to explicitly invalidate (“kill”) a shared buffer after it
> has
> been distributed to importers, so that further CPU and device access
> is
> prevented and importers reliably observe failure.
>
> The change in this series is to properly document and use existing
> core
> “revoked” state on the dma-buf object and a corresponding exporter-
> triggered
> revoke operation. Once a dma-buf is revoked, new access paths are
> blocked so
> that attempts to DMA-map, vmap, or mmap the buffer fail in a
> consistent way.
This sounds like it does not match how many GPU-drivers use the
move_notify() callback.
move_notify() would typically invalidate any device maps and any
asynchronous part of that invalidation would be complete when the dma-
buf's reservation object becomes idle WRT DMA_RESV_USAGE_BOOKKEEP
fences.
However, the importer could, after obtaining the resv lock, obtain a
new map using dma_buf_map_attachment(), and I'd assume the CPU maps
work in the same way, I.E. move_notify() does not *permanently* revoke
importer access.
/Thomas
>
> Thanks
>
> Cc: linux-media@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-sig@lists.linaro.org
> Cc: linux-kernel@vger.kernel.org
> Cc: amd-gfx@lists.freedesktop.org
> Cc: virtualization@lists.linux.dev
> Cc: intel-xe@lists.freedesktop.org
> Cc: linux-rdma@vger.kernel.org
> Cc: iommu@lists.linux.dev
> Cc: kvm@vger.kernel.org
> To: Sumit Semwal <sumit.semwal@linaro.org>
> To: Christian König <christian.koenig@amd.com>
> To: Alex Deucher <alexander.deucher@amd.com>
> To: David Airlie <airlied@gmail.com>
> To: Simona Vetter <simona@ffwll.ch>
> To: Gerd Hoffmann <kraxel@redhat.com>
> To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> To: Gurchetan Singh <gurchetansingh@chromium.org>
> To: Chia-I Wu <olvaffe@gmail.com>
> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> To: Maxime Ripard <mripard@kernel.org>
> To: Thomas Zimmermann <tzimmermann@suse.de>
> To: Lucas De Marchi <lucas.demarchi@intel.com>
> To: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> To: Rodrigo Vivi <rodrigo.vivi@intel.com>
> To: Jason Gunthorpe <jgg@ziepe.ca>
> To: Leon Romanovsky <leon@kernel.org>
> To: Kevin Tian <kevin.tian@intel.com>
> To: Joerg Roedel <joro@8bytes.org>
> To: Will Deacon <will@kernel.org>
> To: Robin Murphy <robin.murphy@arm.com>
> To: Alex Williamson <alex@shazbot.org>
>
> ---
> Leon Romanovsky (4):
> dma-buf: Rename .move_notify() callback to a clearer identifier
> dma-buf: Document revoke semantics
> iommufd: Require DMABUF revoke semantics
> vfio: Add pinned interface to perform revoke semantics
>
> drivers/dma-buf/dma-buf.c | 6 +++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
> drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
> drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
> drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
> drivers/infiniband/core/umem_dmabuf.c | 4 ++--
> drivers/infiniband/hw/mlx5/mr.c | 2 +-
> drivers/iommu/iommufd/pages.c | 11 +++++++++--
> drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++
> include/linux/dma-buf.h | 25
> ++++++++++++++++++++++---
> 10 files changed, 60 insertions(+), 18 deletions(-)
> ---
> base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
> change-id: 20251221-dmabuf-revoke-b90ef16e4236
>
> Best regards,
> --
> Leon Romanovsky <leonro@nvidia.com>
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-18 14:16 ` [PATCH v2 0/4] " Thomas Hellström
@ 2026-01-19 7:52 ` Leon Romanovsky
2026-01-19 9:27 ` Thomas Hellström
0 siblings, 1 reply; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 7:52 UTC (permalink / raw)
To: Thomas Hellström
Cc: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Rodrigo Vivi, Jason Gunthorpe, Kevin Tian,
Joerg Roedel, Will Deacon, Robin Murphy, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On Sun, Jan 18, 2026 at 03:16:25PM +0100, Thomas Hellström wrote:
> Hi, Leon,
>
> On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
> > Changelog:
> > v2:
> > * Changed series to document the revoke semantics instead of
> > implementing it.
> > v1:
> > https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com
> >
> > ---------------------------------------------------------------------
> > ----
> > This series documents a dma-buf “revoke” mechanism: to allow a dma-
> > buf
> > exporter to explicitly invalidate (“kill”) a shared buffer after it
> > has
> > been distributed to importers, so that further CPU and device access
> > is
> > prevented and importers reliably observe failure.
> >
> > The change in this series is to properly document and use existing
> > core
> > “revoked” state on the dma-buf object and a corresponding exporter-
> > triggered
> > revoke operation. Once a dma-buf is revoked, new access paths are
> > blocked so
> > that attempts to DMA-map, vmap, or mmap the buffer fail in a
> > consistent way.
>
> This sounds like it does not match how many GPU-drivers use the
> move_notify() callback.
No change for them.
>
> move_notify() would typically invalidate any device maps and any
> asynchronous part of that invalidation would be complete when the dma-
> buf's reservation object becomes idle WRT DMA_RESV_USAGE_BOOKKEEP
> fences.
This part has not changed and remains the same for the revocation flow as well.
>
> However, the importer could, after obtaining the resv lock, obtain a
> new map using dma_buf_map_attachment(), and I'd assume the CPU maps
> work in the same way, I.E. move_notify() does not *permanently* revoke
> importer access.
This part diverges by design and is documented to match revoke semantics.
It defines what must occur after the exporter requests that the buffer be
"killed". An importer that follows revoke semantics will not attempt to call
dma_buf_map_attachment(), and the exporter will block any remapping attempts
regardless. See the priv->revoked flag in the VFIO exporter.
In addition, in this email thread, Christian explains that revoke
semantics already exists, with the combination of dma_buf_pin and
dma_buf_move_notify, just not documented:
https://lore.kernel.org/all/f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com/
Thanks
>
> /Thomas
>
>
> >
> > Thanks
> >
> > Cc: linux-media@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linaro-mm-sig@lists.linaro.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: amd-gfx@lists.freedesktop.org
> > Cc: virtualization@lists.linux.dev
> > Cc: intel-xe@lists.freedesktop.org
> > Cc: linux-rdma@vger.kernel.org
> > Cc: iommu@lists.linux.dev
> > Cc: kvm@vger.kernel.org
> > To: Sumit Semwal <sumit.semwal@linaro.org>
> > To: Christian König <christian.koenig@amd.com>
> > To: Alex Deucher <alexander.deucher@amd.com>
> > To: David Airlie <airlied@gmail.com>
> > To: Simona Vetter <simona@ffwll.ch>
> > To: Gerd Hoffmann <kraxel@redhat.com>
> > To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > To: Gurchetan Singh <gurchetansingh@chromium.org>
> > To: Chia-I Wu <olvaffe@gmail.com>
> > To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > To: Maxime Ripard <mripard@kernel.org>
> > To: Thomas Zimmermann <tzimmermann@suse.de>
> > To: Lucas De Marchi <lucas.demarchi@intel.com>
> > To: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > To: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > To: Jason Gunthorpe <jgg@ziepe.ca>
> > To: Leon Romanovsky <leon@kernel.org>
> > To: Kevin Tian <kevin.tian@intel.com>
> > To: Joerg Roedel <joro@8bytes.org>
> > To: Will Deacon <will@kernel.org>
> > To: Robin Murphy <robin.murphy@arm.com>
> > To: Alex Williamson <alex@shazbot.org>
> >
> > ---
> > Leon Romanovsky (4):
> > dma-buf: Rename .move_notify() callback to a clearer identifier
> > dma-buf: Document revoke semantics
> > iommufd: Require DMABUF revoke semantics
> > vfio: Add pinned interface to perform revoke semantics
> >
> > drivers/dma-buf/dma-buf.c | 6 +++---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
> > drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
> > drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
> > drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
> > drivers/infiniband/core/umem_dmabuf.c | 4 ++--
> > drivers/infiniband/hw/mlx5/mr.c | 2 +-
> > drivers/iommu/iommufd/pages.c | 11 +++++++++--
> > drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++
> > include/linux/dma-buf.h | 25
> > ++++++++++++++++++++++---
> > 10 files changed, 60 insertions(+), 18 deletions(-)
> > ---
> > base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
> > change-id: 20251221-dmabuf-revoke-b90ef16e4236
> >
> > Best regards,
> > --
> > Leon Romanovsky <leonro@nvidia.com>
> >
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-19 7:52 ` Leon Romanovsky
@ 2026-01-19 9:27 ` Thomas Hellström
2026-01-19 10:20 ` Leon Romanovsky
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Thomas Hellström @ 2026-01-19 9:27 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Rodrigo Vivi, Jason Gunthorpe, Kevin Tian,
Joerg Roedel, Will Deacon, Robin Murphy, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On Mon, 2026-01-19 at 09:52 +0200, Leon Romanovsky wrote:
> On Sun, Jan 18, 2026 at 03:16:25PM +0100, Thomas Hellström wrote:
> > Hi, Leon,
> >
> > On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
> > > Changelog:
> > > v2:
> > > * Changed series to document the revoke semantics instead of
> > > implementing it.
> > > v1:
> > > https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > ----
> > > This series documents a dma-buf “revoke” mechanism: to allow a
> > > dma-
> > > buf
> > > exporter to explicitly invalidate (“kill”) a shared buffer after
> > > it
> > > has
> > > been distributed to importers, so that further CPU and device
> > > access
> > > is
> > > prevented and importers reliably observe failure.
> > >
> > > The change in this series is to properly document and use
> > > existing
> > > core
> > > “revoked” state on the dma-buf object and a corresponding
> > > exporter-
> > > triggered
> > > revoke operation. Once a dma-buf is revoked, new access paths are
> > > blocked so
> > > that attempts to DMA-map, vmap, or mmap the buffer fail in a
> > > consistent way.
> >
> > This sounds like it does not match how many GPU-drivers use the
> > move_notify() callback.
>
> No change for them.
>
> >
> > move_notify() would typically invalidate any device maps and any
> > asynchronous part of that invalidation would be complete when the
> > dma-
> > buf's reservation object becomes idle WRT DMA_RESV_USAGE_BOOKKEEP
> > fences.
>
> This part has not changed and remains the same for the revocation
> flow as well.
>
> >
> > However, the importer could, after obtaining the resv lock, obtain
> > a
> > new map using dma_buf_map_attachment(), and I'd assume the CPU maps
> > work in the same way, I.E. move_notify() does not *permanently*
> > revoke
> > importer access.
>
> This part diverges by design and is documented to match revoke
> semantics.
> It defines what must occur after the exporter requests that the
> buffer be
> "killed". An importer that follows revoke semantics will not attempt
> to call
> dma_buf_map_attachment(), and the exporter will block any remapping
> attempts
> regardless. See the priv->revoked flag in the VFIO exporter.
>
> In addition, in this email thread, Christian explains that revoke
> semantics already exists, with the combination of dma_buf_pin and
> dma_buf_move_notify, just not documented:
> https://lore.kernel.org/all/f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com/
Hmm,
Considering
https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/infiniband/core/umem_dmabuf.c#L192
this sounds like it's not just undocumented but also in some cases
unimplemented. The xe driver for one doesn't expect move_notify() to be
called on pinned buffers, so if that is indeed going to be part of the
dma-buf protocol, wouldn't support for that need to be advertised by
the importer?
Thanks,
Thomas
>
> Thanks
>
> >
> > /Thomas
> >
> >
> > >
> > > Thanks
> > >
> > > Cc: linux-media@vger.kernel.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: linaro-mm-sig@lists.linaro.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: amd-gfx@lists.freedesktop.org
> > > Cc: virtualization@lists.linux.dev
> > > Cc: intel-xe@lists.freedesktop.org
> > > Cc: linux-rdma@vger.kernel.org
> > > Cc: iommu@lists.linux.dev
> > > Cc: kvm@vger.kernel.org
> > > To: Sumit Semwal <sumit.semwal@linaro.org>
> > > To: Christian König <christian.koenig@amd.com>
> > > To: Alex Deucher <alexander.deucher@amd.com>
> > > To: David Airlie <airlied@gmail.com>
> > > To: Simona Vetter <simona@ffwll.ch>
> > > To: Gerd Hoffmann <kraxel@redhat.com>
> > > To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > > To: Gurchetan Singh <gurchetansingh@chromium.org>
> > > To: Chia-I Wu <olvaffe@gmail.com>
> > > To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > To: Maxime Ripard <mripard@kernel.org>
> > > To: Thomas Zimmermann <tzimmermann@suse.de>
> > > To: Lucas De Marchi <lucas.demarchi@intel.com>
> > > To: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > To: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > To: Jason Gunthorpe <jgg@ziepe.ca>
> > > To: Leon Romanovsky <leon@kernel.org>
> > > To: Kevin Tian <kevin.tian@intel.com>
> > > To: Joerg Roedel <joro@8bytes.org>
> > > To: Will Deacon <will@kernel.org>
> > > To: Robin Murphy <robin.murphy@arm.com>
> > > To: Alex Williamson <alex@shazbot.org>
> > >
> > > ---
> > > Leon Romanovsky (4):
> > > dma-buf: Rename .move_notify() callback to a clearer
> > > identifier
> > > dma-buf: Document revoke semantics
> > > iommufd: Require DMABUF revoke semantics
> > > vfio: Add pinned interface to perform revoke semantics
> > >
> > > drivers/dma-buf/dma-buf.c | 6 +++---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
> > > drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
> > > drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
> > > drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
> > > drivers/infiniband/core/umem_dmabuf.c | 4 ++--
> > > drivers/infiniband/hw/mlx5/mr.c | 2 +-
> > > drivers/iommu/iommufd/pages.c | 11 +++++++++--
> > > drivers/vfio/pci/vfio_pci_dmabuf.c | 16
> > > ++++++++++++++++
> > > include/linux/dma-buf.h | 25
> > > ++++++++++++++++++++++---
> > > 10 files changed, 60 insertions(+), 18 deletions(-)
> > > ---
> > > base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
> > > change-id: 20251221-dmabuf-revoke-b90ef16e4236
> > >
> > > Best regards,
> > > --
> > > Leon Romanovsky <leonro@nvidia.com>
> > >
> >
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-19 9:27 ` Thomas Hellström
@ 2026-01-19 10:20 ` Leon Romanovsky
2026-01-19 10:20 ` Christian König
[not found] ` <20260119162424.GE961572@ziepe.ca>
2 siblings, 0 replies; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 10:20 UTC (permalink / raw)
To: Thomas Hellström
Cc: Sumit Semwal, Christian König, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Rodrigo Vivi, Jason Gunthorpe, Kevin Tian,
Joerg Roedel, Will Deacon, Robin Murphy, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On Mon, Jan 19, 2026 at 10:27:00AM +0100, Thomas Hellström wrote:
> On Mon, 2026-01-19 at 09:52 +0200, Leon Romanovsky wrote:
> > On Sun, Jan 18, 2026 at 03:16:25PM +0100, Thomas Hellström wrote:
> > > Hi, Leon,
> > >
> > > On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
> > > > Changelog:
> > > > v2:
> > > > * Changed series to document the revoke semantics instead of
> > > > implementing it.
> > > > v1:
> > > > https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com
> > > >
> > > > -----------------------------------------------------------------
> > > > ----
> > > > ----
> > > > This series documents a dma-buf “revoke” mechanism: to allow a
> > > > dma-
> > > > buf
> > > > exporter to explicitly invalidate (“kill”) a shared buffer after
> > > > it
> > > > has
> > > > been distributed to importers, so that further CPU and device
> > > > access
> > > > is
> > > > prevented and importers reliably observe failure.
> > > >
> > > > The change in this series is to properly document and use
> > > > existing
> > > > core
> > > > “revoked” state on the dma-buf object and a corresponding
> > > > exporter-
> > > > triggered
> > > > revoke operation. Once a dma-buf is revoked, new access paths are
> > > > blocked so
> > > > that attempts to DMA-map, vmap, or mmap the buffer fail in a
> > > > consistent way.
> > >
> > > This sounds like it does not match how many GPU-drivers use the
> > > move_notify() callback.
> >
> > No change for them.
> >
> > >
> > > move_notify() would typically invalidate any device maps and any
> > > asynchronous part of that invalidation would be complete when the
> > > dma-
> > > buf's reservation object becomes idle WRT DMA_RESV_USAGE_BOOKKEEP
> > > fences.
> >
> > This part has not changed and remains the same for the revocation
> > flow as well.
> >
> > >
> > > However, the importer could, after obtaining the resv lock, obtain
> > > a
> > > new map using dma_buf_map_attachment(), and I'd assume the CPU maps
> > > work in the same way, I.E. move_notify() does not *permanently*
> > > revoke
> > > importer access.
> >
> > This part diverges by design and is documented to match revoke
> > semantics.
> > It defines what must occur after the exporter requests that the
> > buffer be
> > "killed". An importer that follows revoke semantics will not attempt
> > to call
> > dma_buf_map_attachment(), and the exporter will block any remapping
> > attempts
> > regardless. See the priv->revoked flag in the VFIO exporter.
> >
> > In addition, in this email thread, Christian explains that revoke
> > semantics already exists, with the combination of dma_buf_pin and
> > dma_buf_move_notify, just not documented:
> > https://lore.kernel.org/all/f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com/
>
>
> Hmm,
>
> Considering
>
> https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/infiniband/core/umem_dmabuf.c#L192
>
> this sounds like it's not just undocumented but also in some cases
> unimplemented.
Yes, it was discussed later in the thread https://lore.kernel.org/all/20260112153503.GF745888@ziepe.ca/.
RDMA will need some adjustments later, but first we need to document the
existing semantics.
> The xe driver for one doesn't expect move_notify() to be
> called on pinned buffers, so if that is indeed going to be part of the
> dma-buf protocol, wouldn't support for that need to be advertised by
> the importer?
This is what Jason proposed with "enum dma_buf_move_notify_level", but
for some reason we got no responses.
Thanks
>
> Thanks,
> Thomas
>
> >
> > Thanks
> >
> > >
> > > /Thomas
> > >
> > >
> > > >
> > > > Thanks
> > > >
> > > > Cc: linux-media@vger.kernel.org
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: linaro-mm-sig@lists.linaro.org
> > > > Cc: linux-kernel@vger.kernel.org
> > > > Cc: amd-gfx@lists.freedesktop.org
> > > > Cc: virtualization@lists.linux.dev
> > > > Cc: intel-xe@lists.freedesktop.org
> > > > Cc: linux-rdma@vger.kernel.org
> > > > Cc: iommu@lists.linux.dev
> > > > Cc: kvm@vger.kernel.org
> > > > To: Sumit Semwal <sumit.semwal@linaro.org>
> > > > To: Christian König <christian.koenig@amd.com>
> > > > To: Alex Deucher <alexander.deucher@amd.com>
> > > > To: David Airlie <airlied@gmail.com>
> > > > To: Simona Vetter <simona@ffwll.ch>
> > > > To: Gerd Hoffmann <kraxel@redhat.com>
> > > > To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > > > To: Gurchetan Singh <gurchetansingh@chromium.org>
> > > > To: Chia-I Wu <olvaffe@gmail.com>
> > > > To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > To: Maxime Ripard <mripard@kernel.org>
> > > > To: Thomas Zimmermann <tzimmermann@suse.de>
> > > > To: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > To: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > > To: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > To: Jason Gunthorpe <jgg@ziepe.ca>
> > > > To: Leon Romanovsky <leon@kernel.org>
> > > > To: Kevin Tian <kevin.tian@intel.com>
> > > > To: Joerg Roedel <joro@8bytes.org>
> > > > To: Will Deacon <will@kernel.org>
> > > > To: Robin Murphy <robin.murphy@arm.com>
> > > > To: Alex Williamson <alex@shazbot.org>
> > > >
> > > > ---
> > > > Leon Romanovsky (4):
> > > > dma-buf: Rename .move_notify() callback to a clearer
> > > > identifier
> > > > dma-buf: Document revoke semantics
> > > > iommufd: Require DMABUF revoke semantics
> > > > vfio: Add pinned interface to perform revoke semantics
> > > >
> > > > drivers/dma-buf/dma-buf.c | 6 +++---
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
> > > > drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
> > > > drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
> > > > drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
> > > > drivers/infiniband/core/umem_dmabuf.c | 4 ++--
> > > > drivers/infiniband/hw/mlx5/mr.c | 2 +-
> > > > drivers/iommu/iommufd/pages.c | 11 +++++++++--
> > > > drivers/vfio/pci/vfio_pci_dmabuf.c | 16
> > > > ++++++++++++++++
> > > > include/linux/dma-buf.h | 25
> > > > ++++++++++++++++++++++---
> > > > 10 files changed, 60 insertions(+), 18 deletions(-)
> > > > ---
> > > > base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
> > > > change-id: 20251221-dmabuf-revoke-b90ef16e4236
> > > >
> > > > Best regards,
> > > > --
> > > > Leon Romanovsky <leonro@nvidia.com>
> > > >
> > >
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-19 9:27 ` Thomas Hellström
2026-01-19 10:20 ` Leon Romanovsky
@ 2026-01-19 10:20 ` Christian König
2026-01-19 10:53 ` Leon Romanovsky
[not found] ` <20260119162424.GE961572@ziepe.ca>
2 siblings, 1 reply; 37+ messages in thread
From: Christian König @ 2026-01-19 10:20 UTC (permalink / raw)
To: Thomas Hellström, Leon Romanovsky
Cc: Sumit Semwal, Alex Deucher, David Airlie, Simona Vetter,
Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh, Chia-I Wu,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Rodrigo Vivi, Jason Gunthorpe, Kevin Tian,
Joerg Roedel, Will Deacon, Robin Murphy, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On 1/19/26 10:27, Thomas Hellström wrote:
> On Mon, 2026-01-19 at 09:52 +0200, Leon Romanovsky wrote:
>> On Sun, Jan 18, 2026 at 03:16:25PM +0100, Thomas Hellström wrote:
>>> Hi, Leon,
>>>
>>> On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
>>>> Changelog:
>>>> v2:
>>>> * Changed series to document the revoke semantics instead of
>>>> implementing it.
>>>> v1:
>>>> https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com
>>>>
>>>> -----------------------------------------------------------------
>>>> ----
>>>> ----
>>>> This series documents a dma-buf “revoke” mechanism: to allow a
>>>> dma-
>>>> buf
>>>> exporter to explicitly invalidate (“kill”) a shared buffer after
>>>> it
>>>> has
>>>> been distributed to importers, so that further CPU and device
>>>> access
>>>> is
>>>> prevented and importers reliably observe failure.
>>>>
>>>> The change in this series is to properly document and use
>>>> existing
>>>> core
>>>> “revoked” state on the dma-buf object and a corresponding
>>>> exporter-
>>>> triggered
>>>> revoke operation. Once a dma-buf is revoked, new access paths are
>>>> blocked so
>>>> that attempts to DMA-map, vmap, or mmap the buffer fail in a
>>>> consistent way.
>>>
>>> This sounds like it does not match how many GPU-drivers use the
>>> move_notify() callback.
>>
>> No change for them.
>>
>>>
>>> move_notify() would typically invalidate any device maps and any
>>> asynchronous part of that invalidation would be complete when the
>>> dma-
>>> buf's reservation object becomes idle WRT DMA_RESV_USAGE_BOOKKEEP
>>> fences.
>>
>> This part has not changed and remains the same for the revocation
>> flow as well.
>>
>>>
>>> However, the importer could, after obtaining the resv lock, obtain
>>> a
>>> new map using dma_buf_map_attachment(), and I'd assume the CPU maps
>>> work in the same way, I.E. move_notify() does not *permanently*
>>> revoke
>>> importer access.
>>
>> This part diverges by design and is documented to match revoke
>> semantics.
Please don't document that. This is specific exporter behavior and doesn't belong into DMA-buf at all.
>> It defines what must occur after the exporter requests that the
>> buffer be
>> "killed". An importer that follows revoke semantics will not attempt
>> to call
>> dma_buf_map_attachment(), and the exporter will block any remapping
>> attempts
>> regardless. See the priv->revoked flag in the VFIO exporter.
I have to clearly reject that.
It's the job of the exporter to reject such calls with an appropriate error and not the importer to not make them.
>> In addition, in this email thread, Christian explains that revoke
>> semantics already exists, with the combination of dma_buf_pin and
>> dma_buf_move_notify, just not documented:
>> https://lore.kernel.org/all/f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com/
>
>
> Hmm,
>
> Considering
>
> https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/infiniband/core/umem_dmabuf.c#L192
Yes, that case is well known.
> this sounds like it's not just undocumented but also in some cases
> unimplemented. The xe driver for one doesn't expect move_notify() to be
> called on pinned buffers,
And that is what we need to change. See move_notify can happen on pinned buffers currently as well.
For example in the case of PCI hot unplug. After pinning we just don't call it for memory management needs any more.
We just haven't documented that properly.
> so if that is indeed going to be part of the
> dma-buf protocol, wouldn't support for that need to be advertised by
> the importer?
That's what this patch set here should do, yes.
Regards,
Christian.
>
> Thanks,
> Thomas
>
>>
>> Thanks
>>
>>>
>>> /Thomas
>>>
>>>
>>>>
>>>> Thanks
>>>>
>>>> Cc: linux-media@vger.kernel.org
>>>> Cc: dri-devel@lists.freedesktop.org
>>>> Cc: linaro-mm-sig@lists.linaro.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: amd-gfx@lists.freedesktop.org
>>>> Cc: virtualization@lists.linux.dev
>>>> Cc: intel-xe@lists.freedesktop.org
>>>> Cc: linux-rdma@vger.kernel.org
>>>> Cc: iommu@lists.linux.dev
>>>> Cc: kvm@vger.kernel.org
>>>> To: Sumit Semwal <sumit.semwal@linaro.org>
>>>> To: Christian König <christian.koenig@amd.com>
>>>> To: Alex Deucher <alexander.deucher@amd.com>
>>>> To: David Airlie <airlied@gmail.com>
>>>> To: Simona Vetter <simona@ffwll.ch>
>>>> To: Gerd Hoffmann <kraxel@redhat.com>
>>>> To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>>> To: Gurchetan Singh <gurchetansingh@chromium.org>
>>>> To: Chia-I Wu <olvaffe@gmail.com>
>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>> To: Maxime Ripard <mripard@kernel.org>
>>>> To: Thomas Zimmermann <tzimmermann@suse.de>
>>>> To: Lucas De Marchi <lucas.demarchi@intel.com>
>>>> To: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>>> To: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>> To: Jason Gunthorpe <jgg@ziepe.ca>
>>>> To: Leon Romanovsky <leon@kernel.org>
>>>> To: Kevin Tian <kevin.tian@intel.com>
>>>> To: Joerg Roedel <joro@8bytes.org>
>>>> To: Will Deacon <will@kernel.org>
>>>> To: Robin Murphy <robin.murphy@arm.com>
>>>> To: Alex Williamson <alex@shazbot.org>
>>>>
>>>> ---
>>>> Leon Romanovsky (4):
>>>> dma-buf: Rename .move_notify() callback to a clearer
>>>> identifier
>>>> dma-buf: Document revoke semantics
>>>> iommufd: Require DMABUF revoke semantics
>>>> vfio: Add pinned interface to perform revoke semantics
>>>>
>>>> drivers/dma-buf/dma-buf.c | 6 +++---
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
>>>> drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
>>>> drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
>>>> drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
>>>> drivers/infiniband/core/umem_dmabuf.c | 4 ++--
>>>> drivers/infiniband/hw/mlx5/mr.c | 2 +-
>>>> drivers/iommu/iommufd/pages.c | 11 +++++++++--
>>>> drivers/vfio/pci/vfio_pci_dmabuf.c | 16
>>>> ++++++++++++++++
>>>> include/linux/dma-buf.h | 25
>>>> ++++++++++++++++++++++---
>>>> 10 files changed, 60 insertions(+), 18 deletions(-)
>>>> ---
>>>> base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
>>>> change-id: 20251221-dmabuf-revoke-b90ef16e4236
>>>>
>>>> Best regards,
>>>> --
>>>> Leon Romanovsky <leonro@nvidia.com>
>>>>
>>>
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-19 10:20 ` Christian König
@ 2026-01-19 10:53 ` Leon Romanovsky
2026-01-19 12:05 ` Christian König
0 siblings, 1 reply; 37+ messages in thread
From: Leon Romanovsky @ 2026-01-19 10:53 UTC (permalink / raw)
To: Christian König
Cc: Thomas Hellström, Sumit Semwal, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Rodrigo Vivi, Jason Gunthorpe, Kevin Tian,
Joerg Roedel, Will Deacon, Robin Murphy, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On Mon, Jan 19, 2026 at 11:20:46AM +0100, Christian König wrote:
> On 1/19/26 10:27, Thomas Hellström wrote:
> > On Mon, 2026-01-19 at 09:52 +0200, Leon Romanovsky wrote:
> >> On Sun, Jan 18, 2026 at 03:16:25PM +0100, Thomas Hellström wrote:
> >>> Hi, Leon,
> >>>
> >>> On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
> >>>> Changelog:
> >>>> v2:
> >>>> * Changed series to document the revoke semantics instead of
> >>>> implementing it.
> >>>> v1:
> >>>> https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com
> >>>>
> >>>> -----------------------------------------------------------------
> >>>> ----
> >>>> ----
> >>>> This series documents a dma-buf “revoke” mechanism: to allow a
> >>>> dma-
> >>>> buf
> >>>> exporter to explicitly invalidate (“kill”) a shared buffer after
> >>>> it
> >>>> has
> >>>> been distributed to importers, so that further CPU and device
> >>>> access
> >>>> is
> >>>> prevented and importers reliably observe failure.
> >>>>
> >>>> The change in this series is to properly document and use
> >>>> existing
> >>>> core
> >>>> “revoked” state on the dma-buf object and a corresponding
> >>>> exporter-
> >>>> triggered
> >>>> revoke operation. Once a dma-buf is revoked, new access paths are
> >>>> blocked so
> >>>> that attempts to DMA-map, vmap, or mmap the buffer fail in a
> >>>> consistent way.
> >>>
> >>> This sounds like it does not match how many GPU-drivers use the
> >>> move_notify() callback.
> >>
> >> No change for them.
> >>
> >>>
> >>> move_notify() would typically invalidate any device maps and any
> >>> asynchronous part of that invalidation would be complete when the
> >>> dma-
> >>> buf's reservation object becomes idle WRT DMA_RESV_USAGE_BOOKKEEP
> >>> fences.
> >>
> >> This part has not changed and remains the same for the revocation
> >> flow as well.
> >>
> >>>
> >>> However, the importer could, after obtaining the resv lock, obtain
> >>> a
> >>> new map using dma_buf_map_attachment(), and I'd assume the CPU maps
> >>> work in the same way, I.E. move_notify() does not *permanently*
> >>> revoke
> >>> importer access.
> >>
> >> This part diverges by design and is documented to match revoke
> >> semantics.
>
> Please don't document that. This is specific exporter behavior and doesn't belong into DMA-buf at all.
>
> >> It defines what must occur after the exporter requests that the
> >> buffer be
> >> "killed". An importer that follows revoke semantics will not attempt
> >> to call
> >> dma_buf_map_attachment(), and the exporter will block any remapping
> >> attempts
> >> regardless. See the priv->revoked flag in the VFIO exporter.
>
> I have to clearly reject that.
>
> It's the job of the exporter to reject such calls with an appropriate error and not the importer to not make them.
Current code behaves as expected: the exporter rejects mapping attempts after
.invalidate_mapping is called, and handles the logic internally.
However, it is not clear what exactly you are proposing. In v1 — which you
objected to — I suggested negotiating revoke support along with the logic for
rejecting mappings in the dma-buf core. In this version, you object to placing
the rejection logic in the exporter.
>
> >> In addition, in this email thread, Christian explains that revoke
> >> semantics already exists, with the combination of dma_buf_pin and
> >> dma_buf_move_notify, just not documented:
> >> https://lore.kernel.org/all/f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com/
> >
> >
> > Hmm,
> >
> > Considering
> >
> > https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/infiniband/core/umem_dmabuf.c#L192
>
> Yes, that case is well known.
>
> > this sounds like it's not just undocumented but also in some cases
> > unimplemented. The xe driver for one doesn't expect move_notify() to be
> > called on pinned buffers,
>
> And that is what we need to change. See move_notify can happen on pinned buffers currently as well.
>
> For example in the case of PCI hot unplug. After pinning we just don't call it for memory management needs any more.
>
> We just haven't documented that properly.
>
> > so if that is indeed going to be part of the
> > dma-buf protocol, wouldn't support for that need to be advertised by
> > the importer?
>
> That's what this patch set here should do, yes.
>
> Regards,
> Christian.
>
> >
> > Thanks,
> > Thomas
> >
> >>
> >> Thanks
> >>
> >>>
> >>> /Thomas
> >>>
> >>>
> >>>>
> >>>> Thanks
> >>>>
> >>>> Cc: linux-media@vger.kernel.org
> >>>> Cc: dri-devel@lists.freedesktop.org
> >>>> Cc: linaro-mm-sig@lists.linaro.org
> >>>> Cc: linux-kernel@vger.kernel.org
> >>>> Cc: amd-gfx@lists.freedesktop.org
> >>>> Cc: virtualization@lists.linux.dev
> >>>> Cc: intel-xe@lists.freedesktop.org
> >>>> Cc: linux-rdma@vger.kernel.org
> >>>> Cc: iommu@lists.linux.dev
> >>>> Cc: kvm@vger.kernel.org
> >>>> To: Sumit Semwal <sumit.semwal@linaro.org>
> >>>> To: Christian König <christian.koenig@amd.com>
> >>>> To: Alex Deucher <alexander.deucher@amd.com>
> >>>> To: David Airlie <airlied@gmail.com>
> >>>> To: Simona Vetter <simona@ffwll.ch>
> >>>> To: Gerd Hoffmann <kraxel@redhat.com>
> >>>> To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> >>>> To: Gurchetan Singh <gurchetansingh@chromium.org>
> >>>> To: Chia-I Wu <olvaffe@gmail.com>
> >>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>> To: Maxime Ripard <mripard@kernel.org>
> >>>> To: Thomas Zimmermann <tzimmermann@suse.de>
> >>>> To: Lucas De Marchi <lucas.demarchi@intel.com>
> >>>> To: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> >>>> To: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >>>> To: Jason Gunthorpe <jgg@ziepe.ca>
> >>>> To: Leon Romanovsky <leon@kernel.org>
> >>>> To: Kevin Tian <kevin.tian@intel.com>
> >>>> To: Joerg Roedel <joro@8bytes.org>
> >>>> To: Will Deacon <will@kernel.org>
> >>>> To: Robin Murphy <robin.murphy@arm.com>
> >>>> To: Alex Williamson <alex@shazbot.org>
> >>>>
> >>>> ---
> >>>> Leon Romanovsky (4):
> >>>> dma-buf: Rename .move_notify() callback to a clearer
> >>>> identifier
> >>>> dma-buf: Document revoke semantics
> >>>> iommufd: Require DMABUF revoke semantics
> >>>> vfio: Add pinned interface to perform revoke semantics
> >>>>
> >>>> drivers/dma-buf/dma-buf.c | 6 +++---
> >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
> >>>> drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
> >>>> drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
> >>>> drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
> >>>> drivers/infiniband/core/umem_dmabuf.c | 4 ++--
> >>>> drivers/infiniband/hw/mlx5/mr.c | 2 +-
> >>>> drivers/iommu/iommufd/pages.c | 11 +++++++++--
> >>>> drivers/vfio/pci/vfio_pci_dmabuf.c | 16
> >>>> ++++++++++++++++
> >>>> include/linux/dma-buf.h | 25
> >>>> ++++++++++++++++++++++---
> >>>> 10 files changed, 60 insertions(+), 18 deletions(-)
> >>>> ---
> >>>> base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
> >>>> change-id: 20251221-dmabuf-revoke-b90ef16e4236
> >>>>
> >>>> Best regards,
> >>>> --
> >>>> Leon Romanovsky <leonro@nvidia.com>
> >>>>
> >>>
> >
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers
2026-01-19 10:53 ` Leon Romanovsky
@ 2026-01-19 12:05 ` Christian König
0 siblings, 0 replies; 37+ messages in thread
From: Christian König @ 2026-01-19 12:05 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Thomas Hellström, Sumit Semwal, Alex Deucher, David Airlie,
Simona Vetter, Gerd Hoffmann, Dmitry Osipenko, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Lucas De Marchi, Rodrigo Vivi, Jason Gunthorpe, Kevin Tian,
Joerg Roedel, Will Deacon, Robin Murphy, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On 1/19/26 11:53, Leon Romanovsky wrote:
> On Mon, Jan 19, 2026 at 11:20:46AM +0100, Christian König wrote:
>> On 1/19/26 10:27, Thomas Hellström wrote:
>>> On Mon, 2026-01-19 at 09:52 +0200, Leon Romanovsky wrote:
>>>> On Sun, Jan 18, 2026 at 03:16:25PM +0100, Thomas Hellström wrote:
>>>>> Hi, Leon,
>>>>>
>>>>> On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
>>>>>> Changelog:
>>>>>> v2:
>>>>>> * Changed series to document the revoke semantics instead of
>>>>>> implementing it.
>>>>>> v1:
>>>>>> https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ----
>>>>>> ----
>>>>>> This series documents a dma-buf “revoke” mechanism: to allow a
>>>>>> dma-
>>>>>> buf
>>>>>> exporter to explicitly invalidate (“kill”) a shared buffer after
>>>>>> it
>>>>>> has
>>>>>> been distributed to importers, so that further CPU and device
>>>>>> access
>>>>>> is
>>>>>> prevented and importers reliably observe failure.
>>>>>>
>>>>>> The change in this series is to properly document and use
>>>>>> existing
>>>>>> core
>>>>>> “revoked” state on the dma-buf object and a corresponding
>>>>>> exporter-
>>>>>> triggered
>>>>>> revoke operation. Once a dma-buf is revoked, new access paths are
>>>>>> blocked so
>>>>>> that attempts to DMA-map, vmap, or mmap the buffer fail in a
>>>>>> consistent way.
>>>>>
>>>>> This sounds like it does not match how many GPU-drivers use the
>>>>> move_notify() callback.
>>>>
>>>> No change for them.
>>>>
>>>>>
>>>>> move_notify() would typically invalidate any device maps and any
>>>>> asynchronous part of that invalidation would be complete when the
>>>>> dma-
>>>>> buf's reservation object becomes idle WRT DMA_RESV_USAGE_BOOKKEEP
>>>>> fences.
>>>>
>>>> This part has not changed and remains the same for the revocation
>>>> flow as well.
>>>>
>>>>>
>>>>> However, the importer could, after obtaining the resv lock, obtain
>>>>> a
>>>>> new map using dma_buf_map_attachment(), and I'd assume the CPU maps
>>>>> work in the same way, I.E. move_notify() does not *permanently*
>>>>> revoke
>>>>> importer access.
>>>>
>>>> This part diverges by design and is documented to match revoke
>>>> semantics.
>>
>> Please don't document that. This is specific exporter behavior and doesn't belong into DMA-buf at all.
>>
>>>> It defines what must occur after the exporter requests that the
>>>> buffer be
>>>> "killed". An importer that follows revoke semantics will not attempt
>>>> to call
>>>> dma_buf_map_attachment(), and the exporter will block any remapping
>>>> attempts
>>>> regardless. See the priv->revoked flag in the VFIO exporter.
>>
>> I have to clearly reject that.
>>
>> It's the job of the exporter to reject such calls with an appropriate error and not the importer to not make them.
>
> Current code behaves as expected: the exporter rejects mapping attempts after
> .invalidate_mapping is called, and handles the logic internally.
>
> However, it is not clear what exactly you are proposing. In v1 — which you
> objected to — I suggested negotiating revoke support along with the logic for
> rejecting mappings in the dma-buf core. In this version, you object to placing
> the rejection logic in the exporter.
Sorry I probably wasn't explaining this correctly.
I was rejecting the idea of doing this in the framework, e.g. the middle layer, or that importers would be force to drop their references.
That an exporter rejects attempts to attach or map a resource is perfectly valid.
Regards,
Christian.
>
>>
>>>> In addition, in this email thread, Christian explains that revoke
>>>> semantics already exists, with the combination of dma_buf_pin and
>>>> dma_buf_move_notify, just not documented:
>>>> https://lore.kernel.org/all/f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com/
>>>
>>>
>>> Hmm,
>>>
>>> Considering
>>>
>>> https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/infiniband/core/umem_dmabuf.c#L192
>>
>> Yes, that case is well known.
>>
>>> this sounds like it's not just undocumented but also in some cases
>>> unimplemented. The xe driver for one doesn't expect move_notify() to be
>>> called on pinned buffers,
>>
>> And that is what we need to change. See move_notify can happen on pinned buffers currently as well.
>>
>> For example in the case of PCI hot unplug. After pinning we just don't call it for memory management needs any more.
>>
>> We just haven't documented that properly.
>>
>>> so if that is indeed going to be part of the
>>> dma-buf protocol, wouldn't support for that need to be advertised by
>>> the importer?
>>
>> That's what this patch set here should do, yes.
>>
>> Regards,
>> Christian.
>>
>>>
>>> Thanks,
>>> Thomas
>>>
>>>>
>>>> Thanks
>>>>
>>>>>
>>>>> /Thomas
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Cc: linux-media@vger.kernel.org
>>>>>> Cc: dri-devel@lists.freedesktop.org
>>>>>> Cc: linaro-mm-sig@lists.linaro.org
>>>>>> Cc: linux-kernel@vger.kernel.org
>>>>>> Cc: amd-gfx@lists.freedesktop.org
>>>>>> Cc: virtualization@lists.linux.dev
>>>>>> Cc: intel-xe@lists.freedesktop.org
>>>>>> Cc: linux-rdma@vger.kernel.org
>>>>>> Cc: iommu@lists.linux.dev
>>>>>> Cc: kvm@vger.kernel.org
>>>>>> To: Sumit Semwal <sumit.semwal@linaro.org>
>>>>>> To: Christian König <christian.koenig@amd.com>
>>>>>> To: Alex Deucher <alexander.deucher@amd.com>
>>>>>> To: David Airlie <airlied@gmail.com>
>>>>>> To: Simona Vetter <simona@ffwll.ch>
>>>>>> To: Gerd Hoffmann <kraxel@redhat.com>
>>>>>> To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>>>>> To: Gurchetan Singh <gurchetansingh@chromium.org>
>>>>>> To: Chia-I Wu <olvaffe@gmail.com>
>>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>> To: Maxime Ripard <mripard@kernel.org>
>>>>>> To: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>> To: Lucas De Marchi <lucas.demarchi@intel.com>
>>>>>> To: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>>>>> To: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>>>> To: Jason Gunthorpe <jgg@ziepe.ca>
>>>>>> To: Leon Romanovsky <leon@kernel.org>
>>>>>> To: Kevin Tian <kevin.tian@intel.com>
>>>>>> To: Joerg Roedel <joro@8bytes.org>
>>>>>> To: Will Deacon <will@kernel.org>
>>>>>> To: Robin Murphy <robin.murphy@arm.com>
>>>>>> To: Alex Williamson <alex@shazbot.org>
>>>>>>
>>>>>> ---
>>>>>> Leon Romanovsky (4):
>>>>>> dma-buf: Rename .move_notify() callback to a clearer
>>>>>> identifier
>>>>>> dma-buf: Document revoke semantics
>>>>>> iommufd: Require DMABUF revoke semantics
>>>>>> vfio: Add pinned interface to perform revoke semantics
>>>>>>
>>>>>> drivers/dma-buf/dma-buf.c | 6 +++---
>>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
>>>>>> drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +-
>>>>>> drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++---
>>>>>> drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
>>>>>> drivers/infiniband/core/umem_dmabuf.c | 4 ++--
>>>>>> drivers/infiniband/hw/mlx5/mr.c | 2 +-
>>>>>> drivers/iommu/iommufd/pages.c | 11 +++++++++--
>>>>>> drivers/vfio/pci/vfio_pci_dmabuf.c | 16
>>>>>> ++++++++++++++++
>>>>>> include/linux/dma-buf.h | 25
>>>>>> ++++++++++++++++++++++---
>>>>>> 10 files changed, 60 insertions(+), 18 deletions(-)
>>>>>> ---
>>>>>> base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
>>>>>> change-id: 20251221-dmabuf-revoke-b90ef16e4236
>>>>>>
>>>>>> Best regards,
>>>>>> --
>>>>>> Leon Romanovsky <leonro@nvidia.com>
>>>>>>
>>>>>
>>>
>>
^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <20260119162424.GE961572@ziepe.ca>]
* Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers
[not found] ` <20260119162424.GE961572@ziepe.ca>
@ 2026-01-19 17:24 ` Thomas Hellström
0 siblings, 0 replies; 37+ messages in thread
From: Thomas Hellström @ 2026-01-19 17:24 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, Sumit Semwal, Christian König, Alex Deucher,
David Airlie, Simona Vetter, Gerd Hoffmann, Dmitry Osipenko,
Gurchetan Singh, Chia-I Wu, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Lucas De Marchi, Rodrigo Vivi, Kevin Tian,
Joerg Roedel, Will Deacon, Robin Murphy, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, amd-gfx,
virtualization, intel-xe, linux-rdma, iommu, kvm
On Mon, 2026-01-19 at 12:24 -0400, Jason Gunthorpe wrote:
> On Mon, Jan 19, 2026 at 10:27:00AM +0100, Thomas Hellström wrote:
> > this sounds like it's not just undocumented but also in some cases
> > unimplemented. The xe driver for one doesn't expect move_notify()
> > to be
> > called on pinned buffers, so if that is indeed going to be part of
> > the
> > dma-buf protocol, wouldn't support for that need to be advertised
> > by
> > the importer?
>
> Can you clarify this?
>
> I don't see xe's importer calling dma_buf_pin() or dma_buf_attach()
> outside of tests? It's importer implements a fully functional looking
> dynamic attach with move_notify()?
>
> I see the exporer is checking for pinned and then not calling
> move_notify - is that what you mean?
No it was if move_notify() is called on a pinned buffer, things will
probably blow up.
And I was under the impression that we'd might be pinning imported
framebuffers but either we don't get any of those or we're using the
incorrect interface to pin, so it might not be a big issue from the xe
side. Need to check this.
In any case we'd want to support revoking also of pinned buffers moving
forward, so question really becomes whether in the mean-time we need to
flag somehow that we don't support it.
Thanks,
Thomas
>
> When I looked through all the importers only RDMA obviously didn't
> support move_notify on pinned buffers.
>
> Jason
^ permalink raw reply [flat|nested] 37+ messages in thread