* [PATCH 1/9] drm/i915: mark dmabuf objects as ALLOC_USER
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
These are userspace objects, so mark them as such. In a later patch it's
useful to determine how paranoid we need to be when managing cache
flushes. In theory no functional changes.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index afa34111de02..5be505ebbb7b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -301,7 +301,8 @@ struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
}
drm_gem_private_object_init(dev, &obj->base, dma_buf->size);
- i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops, &lock_class, 0);
+ i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops, &lock_class,
+ I915_BO_ALLOC_USER);
obj->base.import_attach = attach;
obj->base.resv = dma_buf->resv;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] [PATCH 1/9] drm/i915: mark dmabuf objects as ALLOC_USER
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
These are userspace objects, so mark them as such. In a later patch it's
useful to determine how paranoid we need to be when managing cache
flushes. In theory no functional changes.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index afa34111de02..5be505ebbb7b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -301,7 +301,8 @@ struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
}
drm_gem_private_object_init(dev, &obj->base, dma_buf->size);
- i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops, &lock_class, 0);
+ i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops, &lock_class,
+ I915_BO_ALLOC_USER);
obj->base.import_attach = attach;
obj->base.resv = dma_buf->resv;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 2/9] drm/i915: mark userptr objects as ALLOC_USER
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-18 17:45 ` Matthew Auld
-1 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
These are userspace objects, so mark them as such. In a later patch it's
useful to determine how paranoid we need to be when managing cache
flushes. In theory no functional changes.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 8ea0fa665e53..887aca9e8dd2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -546,7 +546,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
return -ENOMEM;
drm_gem_private_object_init(dev, &obj->base, args->user_size);
- i915_gem_object_init(obj, &i915_gem_userptr_ops, &lock_class, 0);
+ i915_gem_object_init(obj, &i915_gem_userptr_ops, &lock_class,
+ I915_BO_ALLOC_USER);
obj->mem_flags = I915_BO_FLAG_STRUCT_PAGE;
obj->read_domains = I915_GEM_DOMAIN_CPU;
obj->write_domain = I915_GEM_DOMAIN_CPU;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] [PATCH 2/9] drm/i915: mark userptr objects as ALLOC_USER
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
These are userspace objects, so mark them as such. In a later patch it's
useful to determine how paranoid we need to be when managing cache
flushes. In theory no functional changes.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 8ea0fa665e53..887aca9e8dd2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -546,7 +546,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
return -ENOMEM;
drm_gem_private_object_init(dev, &obj->base, args->user_size);
- i915_gem_object_init(obj, &i915_gem_userptr_ops, &lock_class, 0);
+ i915_gem_object_init(obj, &i915_gem_userptr_ops, &lock_class,
+ I915_BO_ALLOC_USER);
obj->mem_flags = I915_BO_FLAG_STRUCT_PAGE;
obj->read_domains = I915_GEM_DOMAIN_CPU;
obj->write_domain = I915_GEM_DOMAIN_CPU;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 3/9] drm/i915: extract bypass-llc check into helper
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-18 17:45 ` Matthew Auld
-1 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
It looks like we will need this in some more places, so extract as a
helper.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 26 ++++++++++++++++++++++
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 17 +-------------
3 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 76ce6a1500bc..1e426a42a36c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -128,6 +128,32 @@ void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE);
}
+bool i915_gem_object_can_bypass_llc(struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
+ /*
+ * This is purely from a security perspective, so we simply don't care
+ * about non-userspace objects being able to bypass the LLC.
+ */
+ if (!(obj->flags & I915_BO_ALLOC_USER))
+ return false;
+
+ /*
+ * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
+ * possible for userspace to bypass the GTT caching bits set by the
+ * kernel, as per the given object cache_level. This is troublesome
+ * since the heavy flush we apply when first gathering the pages is
+ * skipped if the kernel thinks the object is coherent with the GPU. As
+ * a result it might be possible to bypass the cache and read the
+ * contents of the page directly, which could be stale data. If it's
+ * just a case of userspace shooting themselves in the foot then so be
+ * it, but since i915 takes the stance of always zeroing memory before
+ * handing it to userspace, we need to prevent this.
+ */
+ return IS_JSL_EHL(i915);
+}
+
static void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
{
struct drm_i915_gem_object *obj = to_intel_bo(gem);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 9df3ee60604e..59201801cec5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -514,6 +514,7 @@ i915_gem_object_finish_access(struct drm_i915_gem_object *obj)
void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
unsigned int cache_level);
+bool i915_gem_object_can_bypass_llc(struct drm_i915_gem_object *obj);
void i915_gem_object_flush_if_display(struct drm_i915_gem_object *obj);
void i915_gem_object_flush_if_display_locked(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 11f072193f3b..cf11aa7e08a0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -182,22 +182,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj, st);
- /*
- * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
- * possible for userspace to bypass the GTT caching bits set by the
- * kernel, as per the given object cache_level. This is troublesome
- * since the heavy flush we apply when first gathering the pages is
- * skipped if the kernel thinks the object is coherent with the GPU. As
- * a result it might be possible to bypass the cache and read the
- * contents of the page directly, which could be stale data. If it's
- * just a case of userspace shooting themselves in the foot then so be
- * it, but since i915 takes the stance of always zeroing memory before
- * handing it to userspace, we need to prevent this.
- *
- * By setting cache_dirty here we make the clflush in set_pages
- * unconditional on such platforms.
- */
- if (IS_JSL_EHL(i915) && obj->flags & I915_BO_ALLOC_USER)
+ if (i915_gem_object_can_bypass_llc(obj))
obj->cache_dirty = true;
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] [PATCH 3/9] drm/i915: extract bypass-llc check into helper
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
It looks like we will need this in some more places, so extract as a
helper.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 26 ++++++++++++++++++++++
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 17 +-------------
3 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 76ce6a1500bc..1e426a42a36c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -128,6 +128,32 @@ void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE);
}
+bool i915_gem_object_can_bypass_llc(struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
+ /*
+ * This is purely from a security perspective, so we simply don't care
+ * about non-userspace objects being able to bypass the LLC.
+ */
+ if (!(obj->flags & I915_BO_ALLOC_USER))
+ return false;
+
+ /*
+ * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
+ * possible for userspace to bypass the GTT caching bits set by the
+ * kernel, as per the given object cache_level. This is troublesome
+ * since the heavy flush we apply when first gathering the pages is
+ * skipped if the kernel thinks the object is coherent with the GPU. As
+ * a result it might be possible to bypass the cache and read the
+ * contents of the page directly, which could be stale data. If it's
+ * just a case of userspace shooting themselves in the foot then so be
+ * it, but since i915 takes the stance of always zeroing memory before
+ * handing it to userspace, we need to prevent this.
+ */
+ return IS_JSL_EHL(i915);
+}
+
static void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
{
struct drm_i915_gem_object *obj = to_intel_bo(gem);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 9df3ee60604e..59201801cec5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -514,6 +514,7 @@ i915_gem_object_finish_access(struct drm_i915_gem_object *obj)
void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
unsigned int cache_level);
+bool i915_gem_object_can_bypass_llc(struct drm_i915_gem_object *obj);
void i915_gem_object_flush_if_display(struct drm_i915_gem_object *obj);
void i915_gem_object_flush_if_display_locked(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 11f072193f3b..cf11aa7e08a0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -182,22 +182,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj, st);
- /*
- * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
- * possible for userspace to bypass the GTT caching bits set by the
- * kernel, as per the given object cache_level. This is troublesome
- * since the heavy flush we apply when first gathering the pages is
- * skipped if the kernel thinks the object is coherent with the GPU. As
- * a result it might be possible to bypass the cache and read the
- * contents of the page directly, which could be stale data. If it's
- * just a case of userspace shooting themselves in the foot then so be
- * it, but since i915 takes the stance of always zeroing memory before
- * handing it to userspace, we need to prevent this.
- *
- * By setting cache_dirty here we make the clflush in set_pages
- * unconditional on such platforms.
- */
- if (IS_JSL_EHL(i915) && obj->flags & I915_BO_ALLOC_USER)
+ if (i915_gem_object_can_bypass_llc(obj))
obj->cache_dirty = true;
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-18 17:45 ` Matthew Auld
-1 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
As pointed out by Thomas, we likely need to flush the pages here if the
GPU can read the page contents directly from main memory. Underneath we
don't know what the sg_table is pointing to, so just add a
wbinvd_on_all_cpus() here, for now.
Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 5be505ebbb7b..1adcd8e02d29 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -232,6 +232,7 @@ struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int flags)
static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct sg_table *pages;
unsigned int sg_page_sizes;
@@ -242,8 +243,11 @@ static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
if (IS_ERR(pages))
return PTR_ERR(pages);
- sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
+ /* XXX: consider doing a vmap flush or something */
+ if (!HAS_LLC(i915) || i915_gem_object_can_bypass_llc(obj))
+ wbinvd_on_all_cpus();
+ sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
__i915_gem_object_set_pages(obj, pages, sg_page_sizes);
return 0;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
As pointed out by Thomas, we likely need to flush the pages here if the
GPU can read the page contents directly from main memory. Underneath we
don't know what the sg_table is pointing to, so just add a
wbinvd_on_all_cpus() here, for now.
Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 5be505ebbb7b..1adcd8e02d29 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -232,6 +232,7 @@ struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int flags)
static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct sg_table *pages;
unsigned int sg_page_sizes;
@@ -242,8 +243,11 @@ static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
if (IS_ERR(pages))
return PTR_ERR(pages);
- sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
+ /* XXX: consider doing a vmap flush or something */
+ if (!HAS_LLC(i915) || i915_gem_object_can_bypass_llc(obj))
+ wbinvd_on_all_cpus();
+ sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
__i915_gem_object_set_pages(obj, pages, sg_page_sizes);
return 0;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 5/9] drm/i915/userptr: add paranoid flush-on-acquire
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-18 17:45 ` Matthew Auld
-1 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
Even though userptr objects are always coherent with the GPU, with no
way for userspace to change this with the set_caching ioctl, even on
non-LLC platforms, there is still the 'Bypass LCC' mocs setting, which
might permit reading the contents of main memory directly.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 887aca9e8dd2..3173c9f9a040 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -165,8 +165,11 @@ static int i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj)
goto err;
}
- sg_page_sizes = i915_sg_dma_sizes(st->sgl);
+ WARN_ON_ONCE(!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE));
+ if (i915_gem_object_can_bypass_llc(obj))
+ obj->cache_dirty = true;
+ sg_page_sizes = i915_sg_dma_sizes(st->sgl);
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
return 0;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] [PATCH 5/9] drm/i915/userptr: add paranoid flush-on-acquire
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
Even though userptr objects are always coherent with the GPU, with no
way for userspace to change this with the set_caching ioctl, even on
non-LLC platforms, there is still the 'Bypass LCC' mocs setting, which
might permit reading the contents of main memory directly.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 887aca9e8dd2..3173c9f9a040 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -165,8 +165,11 @@ static int i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj)
goto err;
}
- sg_page_sizes = i915_sg_dma_sizes(st->sgl);
+ WARN_ON_ONCE(!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE));
+ if (i915_gem_object_can_bypass_llc(obj))
+ obj->cache_dirty = true;
+ sg_page_sizes = i915_sg_dma_sizes(st->sgl);
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
return 0;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 6/9] drm/i915/shmem: ensure flush during swap-in on non-LLC
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-18 17:45 ` Matthew Auld
-1 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
On non-LLC platforms, force the flush-on-acquire if this is ever
swapped-in. Our async flush path is not trust worthy enough yet(and
happens in the wrong order), and with some tricks it's conceivable for
userspace to change the cache-level to I915_CACHE_NONE after the pages
are swapped-in, and since execbuf binds the object before doing the
async flush, there is a potential race window.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index cf11aa7e08a0..d77da59fae04 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -286,6 +286,8 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
struct sg_table *pages,
bool needs_clflush)
{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
if (obj->mm.madv == I915_MADV_DONTNEED)
@@ -297,6 +299,16 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
drm_clflush_sg(pages);
__start_cpu_write(obj);
+ /*
+ * On non-LLC platforms, force the flush-on-acquire if this is ever
+ * swapped-in. Our async flush path is not trust worthy enough yet(and
+ * happens in the wrong order), and with some tricks it's conceivable
+ * for userspace to change the cache-level to I915_CACHE_NONE after the
+ * pages are swapped-in, and since execbuf binds the object before doing
+ * the async flush, we have a race window.
+ */
+ if (!HAS_LLC(i915))
+ obj->cache_dirty = true;
}
void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct sg_table *pages)
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] [PATCH 6/9] drm/i915/shmem: ensure flush during swap-in on non-LLC
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
On non-LLC platforms, force the flush-on-acquire if this is ever
swapped-in. Our async flush path is not trust worthy enough yet(and
happens in the wrong order), and with some tricks it's conceivable for
userspace to change the cache-level to I915_CACHE_NONE after the pages
are swapped-in, and since execbuf binds the object before doing the
async flush, there is a potential race window.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index cf11aa7e08a0..d77da59fae04 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -286,6 +286,8 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
struct sg_table *pages,
bool needs_clflush)
{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
if (obj->mm.madv == I915_MADV_DONTNEED)
@@ -297,6 +299,16 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
drm_clflush_sg(pages);
__start_cpu_write(obj);
+ /*
+ * On non-LLC platforms, force the flush-on-acquire if this is ever
+ * swapped-in. Our async flush path is not trust worthy enough yet(and
+ * happens in the wrong order), and with some tricks it's conceivable
+ * for userspace to change the cache-level to I915_CACHE_NONE after the
+ * pages are swapped-in, and since execbuf binds the object before doing
+ * the async flush, we have a race window.
+ */
+ if (!HAS_LLC(i915))
+ obj->cache_dirty = true;
}
void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct sg_table *pages)
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 7/9] drm/i915: expand on the kernel-doc for cache_dirty
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-18 17:45 ` Matthew Auld
-1 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström, Daniel Vetter
Add some details around non-LLC platforms and cflushing, when dealing
with the flush-on-acquire, which is potentially security sensitive.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1231224728e4..9c323666bd7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1933,6 +1933,17 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
* !(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ)
* but gcc's optimiser doesn't handle that as well and emits
* two jumps instead of one. Maybe one day...
+ *
+ * FIXME: There is also sync flushing in set_pages(), which
+ * serves a different purpose(some of the time at least).
+ *
+ * We should consider:
+ *
+ * 1. Rip out the async flush code.
+ *
+ * 2. Or make the sync flushing use the async clflush path
+ * using mandatory fences underneath. Currently the below
+ * async flush happens after we bind the object.
*/
if (unlikely(obj->cache_dirty & ~obj->cache_coherent)) {
if (i915_gem_clflush_object(obj, 0))
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 7c3da4e3e737..da85169006d4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -427,6 +427,33 @@ struct drm_i915_gem_object {
* can freely bypass the CPU cache when touching the pages with the GPU,
* where the kernel is completely unaware. On such platform we need
* apply the sledgehammer-on-acquire regardless of the @cache_coherent.
+ *
+ * Special care is taken on non-LLC platforms, to prevent potential
+ * information leak. The driver currently ensures:
+ *
+ * 1. All userspace objects, by default, have @cache_level set as
+ * I915_CACHE_NONE. The only exception is userptr objects, where we
+ * instead force I915_CACHE_LLC, but we also don't allow userspace to
+ * ever change the @cache_level for such objects. Another special case
+ * is dma-buf, which doesn't rely on @cache_dirty, but there we
+ * always do a forced flush when acquiring the pages, if there is a
+ * chance that the pages can be read directly from main memory with
+ * the GPU.
+ *
+ * 2. All I915_CACHE_NONE objects have @cache_dirty initially true.
+ *
+ * 3. All swapped-out objects(i.e shmem) have @cache_dirty set to
+ * true.
+ *
+ * 4. The @cache_dirty is never freely reset before the initial
+ * flush, even if userspace adjusts the @cache_level through the
+ * i915_gem_set_caching_ioctl.
+ *
+ * 5. All @cache_dirty objects(including swapped-in) are initially
+ * flushed with a synchronous call to drm_clflush_sg in
+ * __i915_gem_object_set_pages. The @cache_dirty can be freely reset
+ * at this point. All further asynchronous clfushes are never security
+ * critical, i.e userspace is free to race against itself.
*/
unsigned int cache_dirty:1;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] [PATCH 7/9] drm/i915: expand on the kernel-doc for cache_dirty
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström, Daniel Vetter
Add some details around non-LLC platforms and cflushing, when dealing
with the flush-on-acquire, which is potentially security sensitive.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1231224728e4..9c323666bd7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1933,6 +1933,17 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
* !(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ)
* but gcc's optimiser doesn't handle that as well and emits
* two jumps instead of one. Maybe one day...
+ *
+ * FIXME: There is also sync flushing in set_pages(), which
+ * serves a different purpose(some of the time at least).
+ *
+ * We should consider:
+ *
+ * 1. Rip out the async flush code.
+ *
+ * 2. Or make the sync flushing use the async clflush path
+ * using mandatory fences underneath. Currently the below
+ * async flush happens after we bind the object.
*/
if (unlikely(obj->cache_dirty & ~obj->cache_coherent)) {
if (i915_gem_clflush_object(obj, 0))
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 7c3da4e3e737..da85169006d4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -427,6 +427,33 @@ struct drm_i915_gem_object {
* can freely bypass the CPU cache when touching the pages with the GPU,
* where the kernel is completely unaware. On such platform we need
* apply the sledgehammer-on-acquire regardless of the @cache_coherent.
+ *
+ * Special care is taken on non-LLC platforms, to prevent potential
+ * information leak. The driver currently ensures:
+ *
+ * 1. All userspace objects, by default, have @cache_level set as
+ * I915_CACHE_NONE. The only exception is userptr objects, where we
+ * instead force I915_CACHE_LLC, but we also don't allow userspace to
+ * ever change the @cache_level for such objects. Another special case
+ * is dma-buf, which doesn't rely on @cache_dirty, but there we
+ * always do a forced flush when acquiring the pages, if there is a
+ * chance that the pages can be read directly from main memory with
+ * the GPU.
+ *
+ * 2. All I915_CACHE_NONE objects have @cache_dirty initially true.
+ *
+ * 3. All swapped-out objects(i.e shmem) have @cache_dirty set to
+ * true.
+ *
+ * 4. The @cache_dirty is never freely reset before the initial
+ * flush, even if userspace adjusts the @cache_level through the
+ * i915_gem_set_caching_ioctl.
+ *
+ * 5. All @cache_dirty objects(including swapped-in) are initially
+ * flushed with a synchronous call to drm_clflush_sg in
+ * __i915_gem_object_set_pages. The @cache_dirty can be freely reset
+ * at this point. All further asynchronous clfushes are never security
+ * critical, i.e userspace is free to race against itself.
*/
unsigned int cache_dirty:1;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 8/9] drm/i915: mark up internal objects with start_cpu_write
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-18 17:45 ` Matthew Auld
-1 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
While the pages can't be swapped out, they can be discarded by the shrinker.
Normally such objects are marked with __I915_MADV_PURGED, which can't be
unset, and therefore requires a new object. For kernel internal objects
this is not true, since the madv hint is reset for our special volatile
objects, such that we can re-acquire new pages, if so desired, without
needing a new object. As a result we should probably be paranoid here
and put the object back into the CPU domain when discarding the pages,
and also correctly set cache_dirty, if required.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index e5ae9c06510c..a57a6b7013c2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -134,6 +134,8 @@ static void i915_gem_object_put_pages_internal(struct drm_i915_gem_object *obj,
internal_free_pages(pages);
obj->mm.dirty = false;
+
+ __start_cpu_write(obj);
}
static const struct drm_i915_gem_object_ops i915_gem_object_internal_ops = {
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] [PATCH 8/9] drm/i915: mark up internal objects with start_cpu_write
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
While the pages can't be swapped out, they can be discarded by the shrinker.
Normally such objects are marked with __I915_MADV_PURGED, which can't be
unset, and therefore requires a new object. For kernel internal objects
this is not true, since the madv hint is reset for our special volatile
objects, such that we can re-acquire new pages, if so desired, without
needing a new object. As a result we should probably be paranoid here
and put the object back into the CPU domain when discarding the pages,
and also correctly set cache_dirty, if required.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index e5ae9c06510c..a57a6b7013c2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -134,6 +134,8 @@ static void i915_gem_object_put_pages_internal(struct drm_i915_gem_object *obj,
internal_free_pages(pages);
obj->mm.dirty = false;
+
+ __start_cpu_write(obj);
}
static const struct drm_i915_gem_object_ops i915_gem_object_internal_ops = {
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 9/9] drm/i915/selftests: mark up hugepages object with start_cpu_write
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-18 17:45 ` Matthew Auld
-1 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
Just like we do for internal objects. Also just use
i915_gem_object_set_cache_coherency() here. No need for over-flushing on
LLC platforms.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 41d0680f3bd7..b2003133deaf 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -136,6 +136,8 @@ static void put_huge_pages(struct drm_i915_gem_object *obj,
huge_pages_free_pages(pages);
obj->mm.dirty = false;
+
+ __start_cpu_write(obj);
}
static const struct drm_i915_gem_object_ops huge_page_ops = {
@@ -152,6 +154,7 @@ huge_pages_object(struct drm_i915_private *i915,
{
static struct lock_class_key lock_class;
struct drm_i915_gem_object *obj;
+ unsigned int cache_level;
GEM_BUG_ON(!size);
GEM_BUG_ON(!IS_ALIGNED(size, BIT(__ffs(page_mask))));
@@ -173,7 +176,9 @@ huge_pages_object(struct drm_i915_private *i915,
obj->write_domain = I915_GEM_DOMAIN_CPU;
obj->read_domains = I915_GEM_DOMAIN_CPU;
- obj->cache_level = I915_CACHE_NONE;
+
+ cache_level = HAS_LLC(i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
+ i915_gem_object_set_cache_coherency(obj, cache_level);
obj->mm.page_mask = page_mask;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] [PATCH 9/9] drm/i915/selftests: mark up hugepages object with start_cpu_write
@ 2021-10-18 17:45 ` Matthew Auld
0 siblings, 0 replies; 43+ messages in thread
From: Matthew Auld @ 2021-10-18 17:45 UTC (permalink / raw)
To: intel-gfx; +Cc: dri-devel, Thomas Hellström
Just like we do for internal objects. Also just use
i915_gem_object_set_cache_coherency() here. No need for over-flushing on
LLC platforms.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 41d0680f3bd7..b2003133deaf 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -136,6 +136,8 @@ static void put_huge_pages(struct drm_i915_gem_object *obj,
huge_pages_free_pages(pages);
obj->mm.dirty = false;
+
+ __start_cpu_write(obj);
}
static const struct drm_i915_gem_object_ops huge_page_ops = {
@@ -152,6 +154,7 @@ huge_pages_object(struct drm_i915_private *i915,
{
static struct lock_class_key lock_class;
struct drm_i915_gem_object *obj;
+ unsigned int cache_level;
GEM_BUG_ON(!size);
GEM_BUG_ON(!IS_ALIGNED(size, BIT(__ffs(page_mask))));
@@ -173,7 +176,9 @@ huge_pages_object(struct drm_i915_private *i915,
obj->write_domain = I915_GEM_DOMAIN_CPU;
obj->read_domains = I915_GEM_DOMAIN_CPU;
- obj->cache_level = I915_CACHE_NONE;
+
+ cache_level = HAS_LLC(i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
+ i915_gem_object_set_cache_coherency(obj, cache_level);
obj->mm.page_mask = page_mask;
--
2.26.3
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
` (8 preceding siblings ...)
(?)
@ 2021-10-18 19:11 ` Patchwork
-1 siblings, 0 replies; 43+ messages in thread
From: Patchwork @ 2021-10-18 19:11 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
URL : https://patchwork.freedesktop.org/series/95982/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1ad5557daeac drm/i915: mark dmabuf objects as ALLOC_USER
9dfe83b2167d drm/i915: mark userptr objects as ALLOC_USER
fc3555ba8818 drm/i915: extract bypass-llc check into helper
42a7064ef6ae drm/i915/dmabuf: add paranoid flush-on-acquire
e13b48097394 drm/i915/userptr: add paranoid flush-on-acquire
3fd7ed641f99 drm/i915/shmem: ensure flush during swap-in on non-LLC
db935401f057 drm/i915: expand on the kernel-doc for cache_dirty
49bf1fb0cbbe drm/i915: mark up internal objects with start_cpu_write
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#9:
While the pages can't be swapped out, they can be discarded by the shrinker.
total: 0 errors, 1 warnings, 0 checks, 8 lines checked
ae2c908cf31f drm/i915/selftests: mark up hugepages object with start_cpu_write
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
` (9 preceding siblings ...)
(?)
@ 2021-10-18 19:13 ` Patchwork
-1 siblings, 0 replies; 43+ messages in thread
From: Patchwork @ 2021-10-18 19:13 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
URL : https://patchwork.freedesktop.org/series/95982/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216
+drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080)
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
` (10 preceding siblings ...)
(?)
@ 2021-10-18 19:42 ` Patchwork
-1 siblings, 0 replies; 43+ messages in thread
From: Patchwork @ 2021-10-18 19:42 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 3726 bytes --]
== Series Details ==
Series: series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
URL : https://patchwork.freedesktop.org/series/95982/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10753 -> Patchwork_21376
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/index.html
Known issues
------------
Here are the changes found in Patchwork_21376 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-bsw-n3050/igt@amdgpu/amd_cs_nop@sync-gfx0.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][2] -> [DMESG-WARN][3] ([i915#1982])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-kbl-soraka/igt@i915_module_load@reload.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-kbl-soraka/igt@i915_module_load@reload.html
* igt@i915_pm_rpm@basic-rte:
- fi-skl-6600u: [PASS][4] -> [FAIL][5] ([i915#3049])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-skl-6600u/igt@i915_pm_rpm@basic-rte.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-skl-6600u/igt@i915_pm_rpm@basic-rte.html
#### Possible fixes ####
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [INCOMPLETE][6] ([i915#2940]) -> [PASS][7]
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-bsw-n3050/igt@i915_selftest@live@execlists.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-bsw-n3050/igt@i915_selftest@live@execlists.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][8] ([i915#4269]) -> [PASS][9]
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3049]: https://gitlab.freedesktop.org/drm/intel/issues/3049
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
Participating hosts (39 -> 37)
------------------------------
Missing (2): fi-bsw-cyan bat-dg1-6
Build changes
-------------
* Linux: CI_DRM_10753 -> Patchwork_21376
CI-20190529: 20190529
CI_DRM_10753: 57c1bcf63565db8d65783364c632a04a44bbd616 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6254: 51792e987da03ba2a6faf5857c12f1d173c87def @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21376: ae2c908cf31fc5df4d6767f448ef9d66321fe364 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ae2c908cf31f drm/i915/selftests: mark up hugepages object with start_cpu_write
49bf1fb0cbbe drm/i915: mark up internal objects with start_cpu_write
db935401f057 drm/i915: expand on the kernel-doc for cache_dirty
3fd7ed641f99 drm/i915/shmem: ensure flush during swap-in on non-LLC
e13b48097394 drm/i915/userptr: add paranoid flush-on-acquire
42a7064ef6ae drm/i915/dmabuf: add paranoid flush-on-acquire
fc3555ba8818 drm/i915: extract bypass-llc check into helper
9dfe83b2167d drm/i915: mark userptr objects as ALLOC_USER
1ad5557daeac drm/i915: mark dmabuf objects as ALLOC_USER
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/index.html
[-- Attachment #2: Type: text/html, Size: 4495 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
` (11 preceding siblings ...)
(?)
@ 2021-10-19 2:39 ` Patchwork
-1 siblings, 0 replies; 43+ messages in thread
From: Patchwork @ 2021-10-19 2:39 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30293 bytes --]
== Series Details ==
Series: series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
URL : https://patchwork.freedesktop.org/series/95982/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10753_full -> Patchwork_21376_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_21376_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_create@create-massive:
- shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl2/igt@gem_create@create-massive.html
* igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-snb7/igt@gem_ctx_persistence@legacy-engines-mixed-process.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#2369] / [i915#2481] / [i915#3070])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-iclb1/igt@gem_eio@unwedge-stress.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb8/igt@gem_eio@unwedge-stress.html
- shard-snb: NOTRUN -> [FAIL][5] ([i915#3354])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-snb7/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: NOTRUN -> [FAIL][6] ([i915#2842])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk8/igt@gem_exec_fair@basic-none-rrul@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl: [PASS][7] -> [SKIP][8] ([fdo#109271])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl2/igt@gem_exec_fair@basic-pace@vcs0.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl6/igt@gem_exec_fair@basic-pace@vcs0.html
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb6/igt@gem_exec_fair@basic-pace@vcs0.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb7/igt@gem_exec_fair@basic-pace@vcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb1/igt@gem_exec_fair@basic-pace@vcs1.html
* igt@gem_exec_fence@nb-await@vecs0:
- shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +1 similar issue
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-skl3/igt@gem_exec_fence@nb-await@vecs0.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-skl7/igt@gem_exec_fence@nb-await@vecs0.html
* igt@gem_exec_params@no-blt:
- shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109283])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@gem_exec_params@no-blt.html
* igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][15] ([fdo#112283])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@gem_exec_params@secure-non-master.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][16] -> [SKIP][17] ([i915#2190])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb2/igt@gem_huc_copy@huc-copy.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb6/igt@gem_huc_copy@huc-copy.html
- shard-kbl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl7/igt@gem_huc_copy@huc-copy.html
* igt@gem_mmap_gtt@coherency:
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#111656])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@gem_mmap_gtt@coherency.html
* igt@gem_pread@exhaustion:
- shard-tglb: NOTRUN -> [WARN][20] ([i915#2658])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@gem_pread@exhaustion.html
* igt@gem_pxp@reject-modify-context-protection-on:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#4270])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@gem_pxp@reject-modify-context-protection-on.html
* igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][22] ([i915#768])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb6/igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-yf-tiled.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-apl: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#3323])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl8/igt@gem_userptr_blits@dmabuf-sync.html
* igt@gem_userptr_blits@invalid-mmap-offset-unsync:
- shard-iclb: NOTRUN -> [SKIP][24] ([i915#3297])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@gem_userptr_blits@invalid-mmap-offset-unsync.html
* igt@gem_userptr_blits@vma-merge:
- shard-tglb: NOTRUN -> [FAIL][25] ([i915#3318])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@gem_userptr_blits@vma-merge.html
* igt@gen7_exec_parse@basic-rejected:
- shard-tglb: NOTRUN -> [SKIP][26] ([fdo#109289]) +1 similar issue
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb2/igt@gen7_exec_parse@basic-rejected.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][27] -> [FAIL][28] ([i915#454])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-iclb1/igt@i915_pm_dc@dc6-psr.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb2/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-tglb: NOTRUN -> [WARN][29] ([i915#2681])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@i915_suspend@fence-restore-untiled:
- shard-kbl: NOTRUN -> [DMESG-WARN][30] ([i915#180])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl7/igt@i915_suspend@fence-restore-untiled.html
* igt@kms_atomic_transition@plane-all-modeset-transition:
- shard-tglb: NOTRUN -> [SKIP][31] ([i915#1769])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_atomic_transition@plane-all-modeset-transition.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-apl: NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#3777])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl6/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-tglb: NOTRUN -> [SKIP][33] ([fdo#111615]) +2 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180:
- shard-iclb: NOTRUN -> [SKIP][34] ([fdo#110723])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180.html
* igt@kms_bw@linear-tiling-1-displays-3840x2160p:
- shard-snb: NOTRUN -> [FAIL][35] ([i915#4299])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-snb6/igt@kms_bw@linear-tiling-1-displays-3840x2160p.html
* igt@kms_bw@linear-tiling-2-displays-3840x2160p:
- shard-apl: NOTRUN -> [DMESG-FAIL][36] ([i915#4298])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl8/igt@kms_bw@linear-tiling-2-displays-3840x2160p.html
* igt@kms_bw@linear-tiling-4-displays-2560x1440p:
- shard-kbl: NOTRUN -> [FAIL][37] ([i915#4299])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl7/igt@kms_bw@linear-tiling-4-displays-2560x1440p.html
* igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][38] ([fdo#109271] / [i915#3886])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk8/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][39] ([i915#3689] / [i915#3886])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb2/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs.html
- shard-kbl: NOTRUN -> [SKIP][40] ([fdo#109271] / [i915#3886]) +3 similar issues
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl2/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
- shard-iclb: NOTRUN -> [SKIP][41] ([fdo#109278] / [i915#3886]) +1 similar issue
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_rc_ccs_cc:
- shard-snb: NOTRUN -> [SKIP][42] ([fdo#109271]) +213 similar issues
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-snb7/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][43] ([fdo#109271] / [i915#3886]) +7 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl8/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-yf_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][44] ([i915#3689]) +3 similar issues
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-yf_tiled_ccs.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_ccs:
- shard-glk: NOTRUN -> [SKIP][45] ([fdo#109271]) +41 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk8/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_ccs.html
* igt@kms_chamelium@hdmi-hpd-enable-disable-mode:
- shard-snb: NOTRUN -> [SKIP][46] ([fdo#109271] / [fdo#111827]) +11 similar issues
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-snb6/igt@kms_chamelium@hdmi-hpd-enable-disable-mode.html
* igt@kms_chamelium@vga-hpd:
- shard-apl: NOTRUN -> [SKIP][47] ([fdo#109271] / [fdo#111827]) +17 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl8/igt@kms_chamelium@vga-hpd.html
* igt@kms_chamelium@vga-hpd-without-ddc:
- shard-kbl: NOTRUN -> [SKIP][48] ([fdo#109271] / [fdo#111827]) +10 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl4/igt@kms_chamelium@vga-hpd-without-ddc.html
* igt@kms_color_chamelium@pipe-a-ctm-green-to-red:
- shard-tglb: NOTRUN -> [SKIP][49] ([fdo#109284] / [fdo#111827]) +4 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_color_chamelium@pipe-a-ctm-green-to-red.html
* igt@kms_color_chamelium@pipe-b-gamma:
- shard-skl: NOTRUN -> [SKIP][50] ([fdo#109271] / [fdo#111827]) +1 similar issue
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-skl5/igt@kms_color_chamelium@pipe-b-gamma.html
* igt@kms_color_chamelium@pipe-c-ctm-max:
- shard-iclb: NOTRUN -> [SKIP][51] ([fdo#109284] / [fdo#111827]) +3 similar issues
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@kms_color_chamelium@pipe-c-ctm-max.html
* igt@kms_color_chamelium@pipe-d-ctm-0-75:
- shard-glk: NOTRUN -> [SKIP][52] ([fdo#109271] / [fdo#111827]) +1 similar issue
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk8/igt@kms_color_chamelium@pipe-d-ctm-0-75.html
* igt@kms_content_protection@atomic:
- shard-tglb: NOTRUN -> [SKIP][53] ([fdo#111828])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_content_protection@atomic.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-tglb: [PASS][54] -> [INCOMPLETE][55] ([i915#2411] / [i915#2828] / [i915#456])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb6/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb7/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_crc@pipe-b-cursor-32x32-onscreen:
- shard-tglb: NOTRUN -> [SKIP][56] ([i915#3319])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb2/igt@kms_cursor_crc@pipe-b-cursor-32x32-onscreen.html
* igt@kms_cursor_crc@pipe-c-cursor-512x170-random:
- shard-iclb: NOTRUN -> [SKIP][57] ([fdo#109278] / [fdo#109279])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@kms_cursor_crc@pipe-c-cursor-512x170-random.html
* igt@kms_cursor_crc@pipe-c-cursor-512x512-onscreen:
- shard-tglb: NOTRUN -> [SKIP][58] ([fdo#109279] / [i915#3359]) +2 similar issues
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_cursor_crc@pipe-c-cursor-512x512-onscreen.html
* igt@kms_cursor_crc@pipe-d-cursor-64x64-random:
- shard-iclb: NOTRUN -> [SKIP][59] ([fdo#109278]) +2 similar issues
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@kms_cursor_crc@pipe-d-cursor-64x64-random.html
* igt@kms_cursor_crc@pipe-d-cursor-max-size-offscreen:
- shard-tglb: NOTRUN -> [SKIP][60] ([i915#3359])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_cursor_crc@pipe-d-cursor-max-size-offscreen.html
* igt@kms_cursor_crc@pipe-d-cursor-suspend:
- shard-kbl: NOTRUN -> [SKIP][61] ([fdo#109271]) +118 similar issues
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl2/igt@kms_cursor_crc@pipe-d-cursor-suspend.html
* igt@kms_cursor_legacy@cursora-vs-flipb-atomic-transitions-varying-size:
- shard-iclb: NOTRUN -> [SKIP][62] ([fdo#109274] / [fdo#109278])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb6/igt@kms_cursor_legacy@cursora-vs-flipb-atomic-transitions-varying-size.html
- shard-skl: NOTRUN -> [SKIP][63] ([fdo#109271]) +1 similar issue
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-skl2/igt@kms_cursor_legacy@cursora-vs-flipb-atomic-transitions-varying-size.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-skl: [PASS][64] -> [FAIL][65] ([i915#2346] / [i915#533])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-skl10/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-skl5/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_cursor_legacy@pipe-d-single-bo:
- shard-kbl: NOTRUN -> [SKIP][66] ([fdo#109271] / [i915#533]) +2 similar issues
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl3/igt@kms_cursor_legacy@pipe-d-single-bo.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [PASS][67] -> [INCOMPLETE][68] ([i915#180] / [i915#636])
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl3/igt@kms_fbcon_fbt@fbc-suspend.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl6/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible:
- shard-iclb: NOTRUN -> [SKIP][69] ([fdo#109274])
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible.html
* igt@kms_flip@2x-flip-vs-wf_vblank-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][70] -> [FAIL][71] ([i915#2122])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-glk5/igt@kms_flip@2x-flip-vs-wf_vblank-interruptible@ac-hdmi-a1-hdmi-a2.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk5/igt@kms_flip@2x-flip-vs-wf_vblank-interruptible@ac-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl: [PASS][72] -> [FAIL][73] ([i915#79]) +2 similar issues
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-skl10/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-skl5/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_flip@plain-flip-ts-check@a-hdmi-a1:
- shard-glk: [PASS][74] -> [DMESG-WARN][75] ([i915#118]) +2 similar issues
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-glk2/igt@kms_flip@plain-flip-ts-check@a-hdmi-a1.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk3/igt@kms_flip@plain-flip-ts-check@a-hdmi-a1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs:
- shard-iclb: NOTRUN -> [SKIP][76] ([i915#2587])
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile:
- shard-iclb: [PASS][77] -> [SKIP][78] ([i915#3701])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-iclb1/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs:
- shard-apl: NOTRUN -> [SKIP][79] ([fdo#109271] / [i915#2672])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl7/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-shrfb-draw-render:
- shard-tglb: NOTRUN -> [SKIP][80] ([fdo#111825]) +13 similar issues
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-shrfb-draw-render.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-blt:
- shard-iclb: NOTRUN -> [SKIP][81] ([fdo#109280])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-blt.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-kbl: [PASS][82] -> [DMESG-WARN][83] ([i915#180]) +2 similar issues
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl6/igt@kms_hdr@bpc-switch-suspend.html
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl1/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_hdr@static-toggle:
- shard-iclb: NOTRUN -> [SKIP][84] ([i915#1187])
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@kms_hdr@static-toggle.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-apl: NOTRUN -> [FAIL][85] ([fdo#108145] / [i915#265]) +3 similar issues
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl7/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][86] -> [FAIL][87] ([fdo#108145] / [i915#265]) +1 similar issue
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-skl7/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-kbl: NOTRUN -> [FAIL][88] ([fdo#108145] / [i915#265]) +1 similar issue
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl7/igt@kms_plane_alpha_blend@pipe-c-alpha-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb:
- shard-apl: NOTRUN -> [FAIL][89] ([i915#265])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl6/igt@kms_plane_alpha_blend@pipe-c-alpha-transparent-fb.html
* igt@kms_plane_lowres@pipe-a-tiling-none:
- shard-iclb: NOTRUN -> [SKIP][90] ([i915#3536])
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb6/igt@kms_plane_lowres@pipe-a-tiling-none.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2:
- shard-tglb: NOTRUN -> [SKIP][91] ([i915#2920])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3:
- shard-kbl: NOTRUN -> [SKIP][92] ([fdo#109271] / [i915#658]) +2 similar issues
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl3/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-5:
- shard-apl: NOTRUN -> [SKIP][93] ([fdo#109271] / [i915#658]) +2 similar issues
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl6/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-5.html
* igt@kms_psr2_su@frontbuffer:
- shard-tglb: NOTRUN -> [SKIP][94] ([i915#1911])
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_psr2_su@frontbuffer.html
* igt@kms_psr@psr2_basic:
- shard-tglb: NOTRUN -> [FAIL][95] ([i915#132] / [i915#3467])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb2/igt@kms_psr@psr2_basic.html
* igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: NOTRUN -> [SKIP][96] ([fdo#109441]) +1 similar issue
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html
* igt@kms_psr@psr2_suspend:
- shard-iclb: [PASS][97] -> [SKIP][98] ([fdo#109441]) +2 similar issues
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-iclb2/igt@kms_psr@psr2_suspend.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb4/igt@kms_psr@psr2_suspend.html
* igt@kms_setmode@basic:
- shard-snb: NOTRUN -> [FAIL][99] ([i915#31])
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-snb5/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [PASS][100] -> [DMESG-WARN][101] ([i915#180] / [i915#295])
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl4/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame:
- shard-apl: NOTRUN -> [SKIP][102] ([fdo#109271]) +235 similar issues
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl7/igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame.html
* igt@nouveau_crc@pipe-c-ctx-flip-detection:
- shard-tglb: NOTRUN -> [SKIP][103] ([i915#2530]) +1 similar issue
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@nouveau_crc@pipe-c-ctx-flip-detection.html
* igt@prime_nv_pcopy@test3_3:
- shard-tglb: NOTRUN -> [SKIP][104] ([fdo#109291])
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@prime_nv_pcopy@test3_3.html
* igt@sysfs_clients@fair-0:
- shard-apl: NOTRUN -> [SKIP][105] ([fdo#109271] / [i915#2994]) +3 similar issues
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl7/igt@sysfs_clients@fair-0.html
* igt@sysfs_clients@sema-50:
- shard-iclb: NOTRUN -> [SKIP][106] ([i915#2994])
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb6/igt@sysfs_clients@sema-50.html
* igt@sysfs_clients@split-25:
- shard-tglb: NOTRUN -> [SKIP][107] ([i915#2994])
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@sysfs_clients@split-25.html
* igt@sysfs_clients@split-50:
- shard-kbl: NOTRUN -> [SKIP][108] ([fdo#109271] / [i915#2994]) +1 similar issue
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl7/igt@sysfs_clients@split-50.html
- shard-glk: NOTRUN -> [SKIP][109] ([fdo#109271] / [i915#2994])
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk8/igt@sysfs_clients@split-50.html
#### Possible fixes ####
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl: [DMESG-WARN][110] ([i915#180]) -> [PASS][111] +6 similar issues
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl1/igt@gem_ctx_isolation@preservation-s3@vcs0.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl4/igt@gem_ctx_isolation@preservation-s3@vcs0.html
* igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [TIMEOUT][112] ([i915#3063]) -> [PASS][113]
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb1/igt@gem_eio@in-flight-contexts-10ms.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb2/igt@gem_eio@in-flight-contexts-10ms.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-apl: [FAIL][114] ([i915#2842] / [i915#3468]) -> [PASS][115]
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-apl1/igt@gem_exec_fair@basic-none@vecs0.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl2/igt@gem_exec_fair@basic-none@vecs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [FAIL][116] ([i915#2842]) -> [PASS][117] +1 similar issue
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-glk4/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk4/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-tglb: [FAIL][118] ([i915#2842]) -> [PASS][119]
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb6/igt@gem_exec_fair@basic-pace@rcs0.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb7/igt@gem_exec_fair@basic-pace@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [FAIL][120] ([i915#2849]) -> [PASS][121]
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-iclb7/igt@gem_exec_fair@basic-throttle@rcs0.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb6/igt@gem_exec_fair@basic-throttle@rcs0.html
* igt@i915_selftest@mock@requests:
- shard-glk: [INCOMPLETE][122] -> [PASS][123]
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-glk1/igt@i915_selftest@mock@requests.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk8/igt@i915_selftest@mock@requests.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0:
- shard-kbl: [DMESG-WARN][124] ([i915#62] / [i915#92]) -> [PASS][125] +13 similar issues
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl7/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl7/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-apl: [DMESG-WARN][126] ([i915#180]) -> [PASS][127]
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-apl8/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-tglb: [INCOMPLETE][128] ([i915#2411] / [i915#456]) -> [PASS][129]
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb7/igt@kms_fbcon_fbt@fbc-suspend.html
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@b-edp1:
- shard-skl: [FAIL][130] ([i915#2122]) -> [PASS][131]
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-skl9/igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@b-edp1.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-skl4/igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@b-edp1.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1:
- shard-glk: [FAIL][132] ([i915#79]) -> [PASS][133]
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-glk6/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1.html
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk1/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile:
- shard-iclb: [SKIP][134] ([i915#3701]) -> [PASS][135]
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb4/igt@kms_flip_scale
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/index.html
[-- Attachment #2: Type: text/html, Size: 33765 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 1/9] drm/i915: mark dmabuf objects as ALLOC_USER
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-20 14:34 ` Thomas Hellström
-1 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:34 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> These are userspace objects, so mark them as such. In a later patch
> it's
> useful to determine how paranoid we need to be when managing cache
> flushes. In theory no functional changes.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 1/9] drm/i915: mark dmabuf objects as ALLOC_USER
@ 2021-10-20 14:34 ` Thomas Hellström
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:34 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> These are userspace objects, so mark them as such. In a later patch
> it's
> useful to determine how paranoid we need to be when managing cache
> flushes. In theory no functional changes.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/9] drm/i915: mark userptr objects as ALLOC_USER
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-20 14:36 ` Thomas Hellström
-1 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:36 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> These are userspace objects, so mark them as such. In a later patch
> it's
> useful to determine how paranoid we need to be when managing cache
> flushes. In theory no functional changes.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 2/9] drm/i915: mark userptr objects as ALLOC_USER
@ 2021-10-20 14:36 ` Thomas Hellström
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:36 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> These are userspace objects, so mark them as such. In a later patch
> it's
> useful to determine how paranoid we need to be when managing cache
> flushes. In theory no functional changes.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 3/9] drm/i915: extract bypass-llc check into helper
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-20 14:38 ` Thomas Hellström
-1 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:38 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> It looks like we will need this in some more places, so extract as a
> helper.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 26
> ++++++++++++++++++++++
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 17 +-------------
> 3 files changed, 28 insertions(+), 16 deletions(-)
>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 3/9] drm/i915: extract bypass-llc check into helper
@ 2021-10-20 14:38 ` Thomas Hellström
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:38 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> It looks like we will need this in some more places, so extract as a
> helper.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 26
> ++++++++++++++++++++++
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 17 +-------------
> 3 files changed, 28 insertions(+), 16 deletions(-)
>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
2021-10-18 17:45 ` Matthew Auld
@ 2021-10-20 14:42 ` Thomas Hellström
-1 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:42 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> As pointed out by Thomas, we likely need to flush the pages here if
> the
> GPU can read the page contents directly from main memory. Underneath
> we
> don't know what the sg_table is pointing to, so just add a
> wbinvd_on_all_cpus() here, for now.
>
> Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
@ 2021-10-20 14:42 ` Thomas Hellström
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:42 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> As pointed out by Thomas, we likely need to flush the pages here if
> the
> GPU can read the page contents directly from main memory. Underneath
> we
> don't know what the sg_table is pointing to, so just add a
> wbinvd_on_all_cpus() here, for now.
>
> Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 5/9] drm/i915/userptr: add paranoid flush-on-acquire
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-20 14:52 ` Thomas Hellström
-1 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:52 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On 10/18/21 19:45, Matthew Auld wrote:
> Even though userptr objects are always coherent with the GPU, with no
> way for userspace to change this with the set_caching ioctl, even on
> non-LLC platforms, there is still the 'Bypass LCC' mocs setting, which
> might permit reading the contents of main memory directly.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 887aca9e8dd2..3173c9f9a040 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -165,8 +165,11 @@ static int i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj)
> goto err;
> }
>
> - sg_page_sizes = i915_sg_dma_sizes(st->sgl);
> + WARN_ON_ONCE(!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE));
> + if (i915_gem_object_can_bypass_llc(obj))
> + obj->cache_dirty = true;
>
> + sg_page_sizes = i915_sg_dma_sizes(st->sgl);
> __i915_gem_object_set_pages(obj, st, sg_page_sizes);
>
> return 0;
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 5/9] drm/i915/userptr: add paranoid flush-on-acquire
@ 2021-10-20 14:52 ` Thomas Hellström
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:52 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On 10/18/21 19:45, Matthew Auld wrote:
> Even though userptr objects are always coherent with the GPU, with no
> way for userspace to change this with the set_caching ioctl, even on
> non-LLC platforms, there is still the 'Bypass LCC' mocs setting, which
> might permit reading the contents of main memory directly.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 887aca9e8dd2..3173c9f9a040 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -165,8 +165,11 @@ static int i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj)
> goto err;
> }
>
> - sg_page_sizes = i915_sg_dma_sizes(st->sgl);
> + WARN_ON_ONCE(!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE));
> + if (i915_gem_object_can_bypass_llc(obj))
> + obj->cache_dirty = true;
>
> + sg_page_sizes = i915_sg_dma_sizes(st->sgl);
> __i915_gem_object_set_pages(obj, st, sg_page_sizes);
>
> return 0;
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 6/9] drm/i915/shmem: ensure flush during swap-in on non-LLC
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-20 14:53 ` Thomas Hellström
-1 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:53 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On 10/18/21 19:45, Matthew Auld wrote:
> On non-LLC platforms, force the flush-on-acquire if this is ever
> swapped-in. Our async flush path is not trust worthy enough yet(and
> happens in the wrong order), and with some tricks it's conceivable for
> userspace to change the cache-level to I915_CACHE_NONE after the pages
> are swapped-in, and since execbuf binds the object before doing the
> async flush, there is a potential race window.
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 6/9] drm/i915/shmem: ensure flush during swap-in on non-LLC
@ 2021-10-20 14:53 ` Thomas Hellström
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:53 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On 10/18/21 19:45, Matthew Auld wrote:
> On non-LLC platforms, force the flush-on-acquire if this is ever
> swapped-in. Our async flush path is not trust worthy enough yet(and
> happens in the wrong order), and with some tricks it's conceivable for
> userspace to change the cache-level to I915_CACHE_NONE after the pages
> are swapped-in, and since execbuf binds the object before doing the
> async flush, there is a potential race window.
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 7/9] drm/i915: expand on the kernel-doc for cache_dirty
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-20 14:58 ` Thomas Hellström
-1 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:58 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel, Daniel Vetter
On 10/18/21 19:45, Matthew Auld wrote:
> Add some details around non-LLC platforms and cflushing, when dealing
> with the flush-on-acquire, which is potentially security sensitive.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +++++++++++++++++++
> 2 files changed, 38 insertions(+)
Lgtm.
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 7/9] drm/i915: expand on the kernel-doc for cache_dirty
@ 2021-10-20 14:58 ` Thomas Hellström
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 14:58 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel, Daniel Vetter
On 10/18/21 19:45, Matthew Auld wrote:
> Add some details around non-LLC platforms and cflushing, when dealing
> with the flush-on-acquire, which is potentially security sensitive.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +++++++++++++++++++
> 2 files changed, 38 insertions(+)
Lgtm.
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 8/9] drm/i915: mark up internal objects with start_cpu_write
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-20 15:11 ` Thomas Hellström
-1 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 15:11 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> While the pages can't be swapped out, they can be discarded by the
> shrinker.
> Normally such objects are marked with __I915_MADV_PURGED, which can't
> be
> unset, and therefore requires a new object. For kernel internal
> objects
> this is not true, since the madv hint is reset for our special
> volatile
> objects, such that we can re-acquire new pages, if so desired,
> without
> needing a new object. As a result we should probably be paranoid here
> and put the object back into the CPU domain when discarding the
> pages,
> and also correctly set cache_dirty, if required.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 8/9] drm/i915: mark up internal objects with start_cpu_write
@ 2021-10-20 15:11 ` Thomas Hellström
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 15:11 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> While the pages can't be swapped out, they can be discarded by the
> shrinker.
> Normally such objects are marked with __I915_MADV_PURGED, which can't
> be
> unset, and therefore requires a new object. For kernel internal
> objects
> this is not true, since the madv hint is reset for our special
> volatile
> objects, such that we can re-acquire new pages, if so desired,
> without
> needing a new object. As a result we should probably be paranoid here
> and put the object back into the CPU domain when discarding the
> pages,
> and also correctly set cache_dirty, if required.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 9/9] drm/i915/selftests: mark up hugepages object with start_cpu_write
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
@ 2021-10-20 15:12 ` Thomas Hellström
-1 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 15:12 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> Just like we do for internal objects. Also just use
> i915_gem_object_set_cache_coherency() here. No need for over-flushing
> on
> LLC platforms.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
Reivewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915/selftests: mark up hugepages object with start_cpu_write
@ 2021-10-20 15:12 ` Thomas Hellström
0 siblings, 0 replies; 43+ messages in thread
From: Thomas Hellström @ 2021-10-20 15:12 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> Just like we do for internal objects. Also just use
> i915_gem_object_set_cache_coherency() here. No need for over-flushing
> on
> LLC platforms.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
Reivewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
2021-10-18 17:45 ` Matthew Auld
(?)
(?)
@ 2021-10-22 10:50 ` kernel test robot
-1 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-10-22 10:50 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 2676 bytes --]
Hi Matthew,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.15-rc6 next-20211021]
[cannot apply to drm-tip/drm-tip]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Matthew-Auld/drm-i915-mark-dmabuf-objects-as-ALLOC_USER/20211019-020842
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a015-20211019 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# https://github.com/0day-ci/linux/commit/108491e634ed9e2e220cf01b127399bfa4598764
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Matthew-Auld/drm-i915-mark-dmabuf-objects-as-ALLOC_USER/20211019-020842
git checkout 108491e634ed9e2e220cf01b127399bfa4598764
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: In function 'i915_gem_object_get_pages_dmabuf':
>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:248:3: error: implicit declaration of function 'wbinvd_on_all_cpus' [-Werror=implicit-function-declaration]
248 | wbinvd_on_all_cpus();
| ^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
vim +/wbinvd_on_all_cpus +248 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
232
233 static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
234 {
235 struct drm_i915_private *i915 = to_i915(obj->base.dev);
236 struct sg_table *pages;
237 unsigned int sg_page_sizes;
238
239 assert_object_held(obj);
240
241 pages = dma_buf_map_attachment(obj->base.import_attach,
242 DMA_BIDIRECTIONAL);
243 if (IS_ERR(pages))
244 return PTR_ERR(pages);
245
246 /* XXX: consider doing a vmap flush or something */
247 if (!HAS_LLC(i915) || i915_gem_object_can_bypass_llc(obj))
> 248 wbinvd_on_all_cpus();
249
250 sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
251 __i915_gem_object_set_pages(obj, pages, sg_page_sizes);
252
253 return 0;
254 }
255
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 42994 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
2021-10-18 17:45 ` Matthew Auld
@ 2021-10-26 13:44 ` Guenter Roeck
-1 siblings, 0 replies; 43+ messages in thread
From: Guenter Roeck @ 2021-10-26 13:44 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx, dri-devel, Thomas Hellström
On Mon, Oct 18, 2021 at 06:45:03PM +0100, Matthew Auld wrote:
> As pointed out by Thomas, we likely need to flush the pages here if the
> GPU can read the page contents directly from main memory. Underneath we
> don't know what the sg_table is pointing to, so just add a
> wbinvd_on_all_cpus() here, for now.
>
> Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
With nosmp builds:
Error log:
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: In function 'i915_gem_object_get_pages_dmabuf':
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:248:17: error: implicit declaration of function 'wbinvd_on_all_cpus' [-Werror=implicit-function-declaration]
248 | wbinvd_on_all_cpus();
| ^~~~~~~~~~~~~~~~~~
Guenter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 5be505ebbb7b..1adcd8e02d29 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -232,6 +232,7 @@ struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int flags)
>
> static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct sg_table *pages;
> unsigned int sg_page_sizes;
>
> @@ -242,8 +243,11 @@ static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> if (IS_ERR(pages))
> return PTR_ERR(pages);
>
> - sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
> + /* XXX: consider doing a vmap flush or something */
> + if (!HAS_LLC(i915) || i915_gem_object_can_bypass_llc(obj))
> + wbinvd_on_all_cpus();
>
> + sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
> __i915_gem_object_set_pages(obj, pages, sg_page_sizes);
>
> return 0;
> --
> 2.26.3
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Intel-gfx] [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
@ 2021-10-26 13:44 ` Guenter Roeck
0 siblings, 0 replies; 43+ messages in thread
From: Guenter Roeck @ 2021-10-26 13:44 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx, dri-devel, Thomas Hellström
On Mon, Oct 18, 2021 at 06:45:03PM +0100, Matthew Auld wrote:
> As pointed out by Thomas, we likely need to flush the pages here if the
> GPU can read the page contents directly from main memory. Underneath we
> don't know what the sg_table is pointing to, so just add a
> wbinvd_on_all_cpus() here, for now.
>
> Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
With nosmp builds:
Error log:
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: In function 'i915_gem_object_get_pages_dmabuf':
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:248:17: error: implicit declaration of function 'wbinvd_on_all_cpus' [-Werror=implicit-function-declaration]
248 | wbinvd_on_all_cpus();
| ^~~~~~~~~~~~~~~~~~
Guenter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 5be505ebbb7b..1adcd8e02d29 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -232,6 +232,7 @@ struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int flags)
>
> static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct sg_table *pages;
> unsigned int sg_page_sizes;
>
> @@ -242,8 +243,11 @@ static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> if (IS_ERR(pages))
> return PTR_ERR(pages);
>
> - sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
> + /* XXX: consider doing a vmap flush or something */
> + if (!HAS_LLC(i915) || i915_gem_object_can_bypass_llc(obj))
> + wbinvd_on_all_cpus();
>
> + sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
> __i915_gem_object_set_pages(obj, pages, sg_page_sizes);
>
> return 0;
> --
> 2.26.3
>
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2021-10-26 13:44 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-18 17:45 [PATCH 1/9] drm/i915: mark dmabuf objects as ALLOC_USER Matthew Auld
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
2021-10-18 17:45 ` [PATCH 2/9] drm/i915: mark userptr " Matthew Auld
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
2021-10-20 14:36 ` Thomas Hellström
2021-10-20 14:36 ` [Intel-gfx] " Thomas Hellström
2021-10-18 17:45 ` [PATCH 3/9] drm/i915: extract bypass-llc check into helper Matthew Auld
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
2021-10-20 14:38 ` Thomas Hellström
2021-10-20 14:38 ` [Intel-gfx] " Thomas Hellström
2021-10-18 17:45 ` [Intel-gfx] [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire Matthew Auld
2021-10-18 17:45 ` Matthew Auld
2021-10-20 14:42 ` Thomas Hellström
2021-10-20 14:42 ` [Intel-gfx] " Thomas Hellström
2021-10-22 10:50 ` kernel test robot
2021-10-26 13:44 ` Guenter Roeck
2021-10-26 13:44 ` [Intel-gfx] " Guenter Roeck
2021-10-18 17:45 ` [PATCH 5/9] drm/i915/userptr: " Matthew Auld
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
2021-10-20 14:52 ` Thomas Hellström
2021-10-20 14:52 ` [Intel-gfx] " Thomas Hellström
2021-10-18 17:45 ` [PATCH 6/9] drm/i915/shmem: ensure flush during swap-in on non-LLC Matthew Auld
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
2021-10-20 14:53 ` Thomas Hellström
2021-10-20 14:53 ` [Intel-gfx] " Thomas Hellström
2021-10-18 17:45 ` [PATCH 7/9] drm/i915: expand on the kernel-doc for cache_dirty Matthew Auld
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
2021-10-20 14:58 ` Thomas Hellström
2021-10-20 14:58 ` [Intel-gfx] " Thomas Hellström
2021-10-18 17:45 ` [PATCH 8/9] drm/i915: mark up internal objects with start_cpu_write Matthew Auld
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
2021-10-20 15:11 ` Thomas Hellström
2021-10-20 15:11 ` [Intel-gfx] " Thomas Hellström
2021-10-18 17:45 ` [PATCH 9/9] drm/i915/selftests: mark up hugepages object " Matthew Auld
2021-10-18 17:45 ` [Intel-gfx] " Matthew Auld
2021-10-20 15:12 ` Thomas Hellström
2021-10-20 15:12 ` [Intel-gfx] " Thomas Hellström
2021-10-18 19:11 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER Patchwork
2021-10-18 19:13 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-18 19:42 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-10-19 2:39 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-10-20 14:34 ` [PATCH 1/9] " Thomas Hellström
2021-10-20 14:34 ` [Intel-gfx] " Thomas Hellström
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.