* [Intel-gfx] [PATCH 0/1] DGFX mmap with rpm
@ 2022-08-25 10:54 Anshuman Gupta
2022-08-25 10:54 ` [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend Anshuman Gupta
` (3 more replies)
0 siblings, 4 replies; 9+ messages in thread
From: Anshuman Gupta @ 2022-08-25 10:54 UTC (permalink / raw)
To: intel-gfx; +Cc: chris, matthew.auld, rodrigo.vivi
As per PCIe Spec Section 5.3.1.4.1
When pcie function is in d3hot state,
Configuration and Message requests are the only TLPs accepted by a
Function in the D3hot state. All other received Requests must be
handled as Unsupported Requests, and all received Completions
may optionally be handled as Unexpected Completions.
Therefore when gfx endpoint function is in d3 state, all pcie iomem
transaction requires to transition the pcie function in D0 state.
This is formal patch extension of
RFC proposal https://patchwork.freedesktop.org/series/107400/
Implementation of handling i915_gem_object_pin_map will be handled in
different series.
Anshuman Gupta (1):
drm/i915/dgfx: Release mmap on rpm suspend
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 48 ++++++++++++++++---
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/i915_gem.c | 8 ++++
5 files changed, 57 insertions(+), 7 deletions(-)
--
2.26.2
^ permalink raw reply [flat|nested] 9+ messages in thread* [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend 2022-08-25 10:54 [Intel-gfx] [PATCH 0/1] DGFX mmap with rpm Anshuman Gupta @ 2022-08-25 10:54 ` Anshuman Gupta 2022-08-26 17:38 ` Matthew Auld 2022-08-25 12:27 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for DGFX mmap with rpm (rev2) Patchwork ` (2 subsequent siblings) 3 siblings, 1 reply; 9+ messages in thread From: Anshuman Gupta @ 2022-08-25 10:54 UTC (permalink / raw) To: intel-gfx; +Cc: chris, matthew.auld, rodrigo.vivi Release all mmap mapping for all lmem objects which are associated with userfault such that, while pcie function in D3hot, any access to memory mappings will raise a userfault. Runtime resume the dgpu(when gem object lies in lmem). This will transition the dgpu graphics function to D0 state if it was in D3 in order to access the mmap memory mappings. v2: - Squashes the patches. [Matt Auld] - Add adequate locking for lmem_userfault_list addition. [Matt Auld] - Reused obj->userfault_count to avoid double addition. [Matt Auld] - Added i915_gem_object_lock to check i915_gem_object_is_lmem. [Matt Auld] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> --- .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 48 ++++++++++++++++--- drivers/gpu/drm/i915/gt/intel_gt.c | 2 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++ drivers/gpu/drm/i915/i915_gem.c | 8 ++++ 5 files changed, 57 insertions(+), 7 deletions(-) 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 9f6b14ec189a..40305e2bcd49 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h @@ -298,7 +298,8 @@ struct drm_i915_gem_object { }; /** - * Whether the object is currently in the GGTT mmap. + * Whether the object is currently in the GGTT or any other supported + * fake offset mmap backed by lmem. */ unsigned int userfault_count; struct list_head userfault_link; diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c index 5a5cf332d8a5..6532a634bd20 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c @@ -1014,12 +1014,29 @@ static void i915_ttm_delayed_free(struct drm_i915_gem_object *obj) ttm_bo_put(i915_gem_to_ttm(obj)); } +static intel_wakeref_t +i915_gem_ttm_get_lmem_obj_wakeref(struct drm_i915_gem_object *obj) +{ + intel_wakeref_t wakeref = 0; + + if (i915_gem_object_lock_interruptible(obj, NULL)) + return 0; + + if (i915_gem_object_is_lmem(obj)) + wakeref = intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm); + + i915_gem_object_unlock(obj); + + return wakeref; +} + static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) { struct vm_area_struct *area = vmf->vma; struct ttm_buffer_object *bo = area->vm_private_data; struct drm_device *dev = bo->base.dev; struct drm_i915_gem_object *obj; + intel_wakeref_t wakeref = 0; vm_fault_t ret; int idx; @@ -1027,18 +1044,23 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) if (!obj) return VM_FAULT_SIGBUS; + wakeref = i915_gem_ttm_get_lmem_obj_wakeref(obj); + /* Sanity check that we allow writing into this object */ if (unlikely(i915_gem_object_is_readonly(obj) && - area->vm_flags & VM_WRITE)) - return VM_FAULT_SIGBUS; + area->vm_flags & VM_WRITE)) { + ret = VM_FAULT_SIGBUS; + goto out_rpm; + } ret = ttm_bo_vm_reserve(bo, vmf); if (ret) - return ret; + goto out_rpm; if (obj->mm.madv != I915_MADV_WILLNEED) { dma_resv_unlock(bo->base.resv); - return VM_FAULT_SIGBUS; + ret = VM_FAULT_SIGBUS; + goto out_rpm; } if (!i915_ttm_resource_mappable(bo->resource)) { @@ -1062,7 +1084,8 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) if (err) { drm_dbg(dev, "Unable to make resource CPU accessible\n"); dma_resv_unlock(bo->base.resv); - return VM_FAULT_SIGBUS; + ret = VM_FAULT_SIGBUS; + goto out_rpm; } } @@ -1073,12 +1096,25 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) } else { ret = ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot); } + + /* ttm_bo_vm_reserve() already has dma_resv_lock */ + if (!ret && i915_gem_object_is_lmem(obj) && !obj->userfault_count++) { + mutex_lock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock); + list_add(&obj->userfault_link, &to_gt(to_i915(obj->base.dev))->lmem_userfault_list); + mutex_unlock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock); + } + if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) - return ret; + goto out_rpm; i915_ttm_adjust_lru(obj); dma_resv_unlock(bo->base.resv); + +out_rpm: + if (wakeref) + intel_runtime_pm_put(&to_i915(obj->base.dev)->runtime_pm, wakeref); + return ret; } diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c index e4bac2431e41..63616ea198ca 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt.c +++ b/drivers/gpu/drm/i915/gt/intel_gt.c @@ -39,6 +39,8 @@ static void __intel_gt_init_early(struct intel_gt *gt) { spin_lock_init(>->irq_lock); + INIT_LIST_HEAD(>->lmem_userfault_list); + mutex_init(>->lmem_userfault_lock); INIT_LIST_HEAD(>->closed_vma); spin_lock_init(>->closed_lock); diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h b/drivers/gpu/drm/i915/gt/intel_gt_types.h index 4d56f7d5a3be..330e7531cf22 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h @@ -132,6 +132,9 @@ struct intel_gt { struct intel_wakeref wakeref; atomic_t user_wakeref; + struct mutex lmem_userfault_lock; /* Protects access to usefault list */ + struct list_head lmem_userfault_list; + struct list_head closed_vma; spinlock_t closed_lock; /* guards the list of closed_vma */ diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 702e5b89be22..288dc7e231dc 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -842,6 +842,14 @@ void i915_gem_runtime_suspend(struct drm_i915_private *i915) &to_gt(i915)->ggtt->userfault_list, userfault_link) __i915_gem_object_release_mmap_gtt(obj); + list_for_each_entry_safe(obj, on, + &to_gt(i915)->lmem_userfault_list, userfault_link) { + i915_gem_object_release_mmap_offset(obj); + + if (!--obj->userfault_count) + list_del(&obj->userfault_link); + } + /* * The fence will be lost when the device powers down. If any were * in use by hardware (i.e. they are pinned), we should not be powering -- 2.26.2 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend 2022-08-25 10:54 ` [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend Anshuman Gupta @ 2022-08-26 17:38 ` Matthew Auld 2022-08-29 11:15 ` Gupta, Anshuman 0 siblings, 1 reply; 9+ messages in thread From: Matthew Auld @ 2022-08-26 17:38 UTC (permalink / raw) To: Anshuman Gupta, intel-gfx; +Cc: chris, rodrigo.vivi On 25/08/2022 11:54, Anshuman Gupta wrote: > Release all mmap mapping for all lmem objects which are associated > with userfault such that, while pcie function in D3hot, any access > to memory mappings will raise a userfault. > > Runtime resume the dgpu(when gem object lies in lmem). > This will transition the dgpu graphics function to D0 > state if it was in D3 in order to access the mmap memory > mappings. > > v2: > - Squashes the patches. [Matt Auld] > - Add adequate locking for lmem_userfault_list addition. [Matt Auld] > - Reused obj->userfault_count to avoid double addition. [Matt Auld] > - Added i915_gem_object_lock to check > i915_gem_object_is_lmem. [Matt Auld] > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331 Just double checking, this is needed for DG1 and DG2, right? Are there any BSpec links we can add here? > Cc: Matthew Auld <matthew.auld@intel.com> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > --- > .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 48 ++++++++++++++++--- > drivers/gpu/drm/i915/gt/intel_gt.c | 2 + > drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++ > drivers/gpu/drm/i915/i915_gem.c | 8 ++++ > 5 files changed, 57 insertions(+), 7 deletions(-) > > 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 9f6b14ec189a..40305e2bcd49 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > @@ -298,7 +298,8 @@ struct drm_i915_gem_object { > }; > > /** > - * Whether the object is currently in the GGTT mmap. > + * Whether the object is currently in the GGTT or any other supported > + * fake offset mmap backed by lmem. > */ > unsigned int userfault_count; > struct list_head userfault_link; > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > index 5a5cf332d8a5..6532a634bd20 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > @@ -1014,12 +1014,29 @@ static void i915_ttm_delayed_free(struct drm_i915_gem_object *obj) > ttm_bo_put(i915_gem_to_ttm(obj)); > } > > +static intel_wakeref_t > +i915_gem_ttm_get_lmem_obj_wakeref(struct drm_i915_gem_object *obj) > +{ > + intel_wakeref_t wakeref = 0; > + > + if (i915_gem_object_lock_interruptible(obj, NULL)) > + return 0; > + > + if (i915_gem_object_is_lmem(obj)) > + wakeref = intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm); > + > + i915_gem_object_unlock(obj); > + > + return wakeref; > +} > + > static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) > { > struct vm_area_struct *area = vmf->vma; > struct ttm_buffer_object *bo = area->vm_private_data; > struct drm_device *dev = bo->base.dev; > struct drm_i915_gem_object *obj; > + intel_wakeref_t wakeref = 0; > vm_fault_t ret; > int idx; > > @@ -1027,18 +1044,23 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) > if (!obj) > return VM_FAULT_SIGBUS; > > + wakeref = i915_gem_ttm_get_lmem_obj_wakeref(obj); We shouldn't drop the lock here (also failing to acquire the lock should be fatal), since the object can in thoery transition to/from lmem inbetween dropping the object lock here and re-acquiring it again below, which means we might skip grabbing the wakeref here, but then later touch the list, if say it moves to lmem. > + > /* Sanity check that we allow writing into this object */ > if (unlikely(i915_gem_object_is_readonly(obj) && > - area->vm_flags & VM_WRITE)) > - return VM_FAULT_SIGBUS; > + area->vm_flags & VM_WRITE)) { > + ret = VM_FAULT_SIGBUS; > + goto out_rpm; > + } > > ret = ttm_bo_vm_reserve(bo, vmf); > if (ret) > - return ret; > + goto out_rpm; > > if (obj->mm.madv != I915_MADV_WILLNEED) { > dma_resv_unlock(bo->base.resv); > - return VM_FAULT_SIGBUS; > + ret = VM_FAULT_SIGBUS; > + goto out_rpm; > } > > if (!i915_ttm_resource_mappable(bo->resource)) { > @@ -1062,7 +1084,8 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) > if (err) { > drm_dbg(dev, "Unable to make resource CPU accessible\n"); > dma_resv_unlock(bo->base.resv); > - return VM_FAULT_SIGBUS; > + ret = VM_FAULT_SIGBUS; > + goto out_rpm; > } > } > > @@ -1073,12 +1096,25 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) > } else { > ret = ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot); > } > + > + /* ttm_bo_vm_reserve() already has dma_resv_lock */ > + if (!ret && i915_gem_object_is_lmem(obj) && !obj->userfault_count++) { This might increment userfault_count more than once per mapping/object? Is that intentional? I would have thought that with fault_ttm the user_fault_count shouldn't ever be > 1 (there is no partial mmap here). Also it look like ret == VM_FAULT_NOPAGE if all went well. Although it also returns that if the wait was interrupted, but I don't think that matters much. Maybe we can do something like: ret = ttm_bo_vm_reserve(bo..) /* locks the object for us */ .. wakeref = 0; if (i915_ttm_cpu_maps_iomem(bo->resource)) wakeref = intel_runtime_pm_get(); if (drm_dev_enter(dev, &idx)) { } else { } if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) goto out_rpm; if (ret == VM_FAULT_NOPAGE && wakeref && !obj->userfault_count) { obj->userfault_count++; /* protected by wakeref */ mutex_lock() list_add(); mutex_unlock(); } ? AFAICT we are then still missing something for object destruction, to ensure we remove the object from the list. Otherwise we can destroy the object, and then at some later point i915_gem_runtime_suspend() runs and will uaf on the list. I think the trick with GTT mmap is that it will always grab the wakeref when unbinding the vma (like during object destruction), and then it can safely remove the object from the list. Perhaps we will need a similar trick anyway, since destroying the object will likely require unbinding it, which will mean touching the page-tables from the CPU, which are in lmem anyway. Do we maybe just always grab the wakeref for dgpu? What do you think? Also on second thought it looks like we can't directly call i915_gem_object_release_mmap_offset() from i915_gem_runtime_suspend(), without then also holding the object lock for the ttm_mem_io_free(). But I think it should be OK to just directly call drm_vma_node_unmap(&bo->base.vma_node, ...) instead. Also, do you know if we need something like CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND here? > + mutex_lock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock); > + list_add(&obj->userfault_link, &to_gt(to_i915(obj->base.dev))->lmem_userfault_list); > + mutex_unlock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock); > + } > + > if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) > - return ret; > + goto out_rpm; > > i915_ttm_adjust_lru(obj); > > dma_resv_unlock(bo->base.resv); > + > +out_rpm: > + if (wakeref) > + intel_runtime_pm_put(&to_i915(obj->base.dev)->runtime_pm, wakeref); > + > return ret; > } > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c > index e4bac2431e41..63616ea198ca 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > @@ -39,6 +39,8 @@ static void __intel_gt_init_early(struct intel_gt *gt) > { > spin_lock_init(>->irq_lock); > > + INIT_LIST_HEAD(>->lmem_userfault_list); > + mutex_init(>->lmem_userfault_lock); > INIT_LIST_HEAD(>->closed_vma); > spin_lock_init(>->closed_lock); > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h b/drivers/gpu/drm/i915/gt/intel_gt_types.h > index 4d56f7d5a3be..330e7531cf22 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h > @@ -132,6 +132,9 @@ struct intel_gt { > struct intel_wakeref wakeref; > atomic_t user_wakeref; > > + struct mutex lmem_userfault_lock; /* Protects access to usefault list */ > + struct list_head lmem_userfault_list; > + > struct list_head closed_vma; > spinlock_t closed_lock; /* guards the list of closed_vma */ > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 702e5b89be22..288dc7e231dc 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -842,6 +842,14 @@ void i915_gem_runtime_suspend(struct drm_i915_private *i915) > &to_gt(i915)->ggtt->userfault_list, userfault_link) > __i915_gem_object_release_mmap_gtt(obj); > > + list_for_each_entry_safe(obj, on, > + &to_gt(i915)->lmem_userfault_list, userfault_link) { > + i915_gem_object_release_mmap_offset(obj); > + > + if (!--obj->userfault_count) > + list_del(&obj->userfault_link); > + } > + > /* > * The fence will be lost when the device powers down. If any were > * in use by hardware (i.e. they are pinned), we should not be powering ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend 2022-08-26 17:38 ` Matthew Auld @ 2022-08-29 11:15 ` Gupta, Anshuman 2022-08-30 13:39 ` Matthew Auld 0 siblings, 1 reply; 9+ messages in thread From: Gupta, Anshuman @ 2022-08-29 11:15 UTC (permalink / raw) To: Auld, Matthew, intel-gfx@lists.freedesktop.org Cc: chris@chris-wilson.co.uk, Vivi, Rodrigo > -----Original Message----- > From: Auld, Matthew <matthew.auld@intel.com> Thanks Matt for reviewing this. > Sent: Friday, August 26, 2022 11:09 PM > To: Gupta, Anshuman <anshuman.gupta@intel.com>; intel- > gfx@lists.freedesktop.org > Cc: joonas.lahtinen@linux.intel.com; Vivi, Rodrigo <rodrigo.vivi@intel.com>; > Nilawar, Badal <badal.nilawar@intel.com>; chris@chris-wilson.co.uk > Subject: Re: [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend > > On 25/08/2022 11:54, Anshuman Gupta wrote: > > Release all mmap mapping for all lmem objects which are associated > > with userfault such that, while pcie function in D3hot, any access to > > memory mappings will raise a userfault. > > > > Runtime resume the dgpu(when gem object lies in lmem). > > This will transition the dgpu graphics function to D0 state if it was > > in D3 in order to access the mmap memory mappings. > > > > v2: > > - Squashes the patches. [Matt Auld] > > - Add adequate locking for lmem_userfault_list addition. [Matt Auld] > > - Reused obj->userfault_count to avoid double addition. [Matt Auld] > > - Added i915_gem_object_lock to check > > i915_gem_object_is_lmem. [Matt Auld] > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331 > > Just double checking, this is needed for DG1 and DG2, right? Are there any BSpec > links we can add here? This is specific to all discrete products with respect to PCIe Spec Section 5.3.1.4.1 I will add the PCIe specs link here. > > > Cc: Matthew Auld <matthew.auld@intel.com> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > > --- > > .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 48 ++++++++++++++++--- > > drivers/gpu/drm/i915/gt/intel_gt.c | 2 + > > drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++ > > drivers/gpu/drm/i915/i915_gem.c | 8 ++++ > > 5 files changed, 57 insertions(+), 7 deletions(-) > > > > 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 9f6b14ec189a..40305e2bcd49 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > > @@ -298,7 +298,8 @@ struct drm_i915_gem_object { > > }; > > > > /** > > - * Whether the object is currently in the GGTT mmap. > > + * Whether the object is currently in the GGTT or any other supported > > + * fake offset mmap backed by lmem. > > */ > > unsigned int userfault_count; > > struct list_head userfault_link; > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > index 5a5cf332d8a5..6532a634bd20 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > @@ -1014,12 +1014,29 @@ static void i915_ttm_delayed_free(struct > drm_i915_gem_object *obj) > > ttm_bo_put(i915_gem_to_ttm(obj)); > > } > > > > +static intel_wakeref_t > > +i915_gem_ttm_get_lmem_obj_wakeref(struct drm_i915_gem_object *obj) { > > + intel_wakeref_t wakeref = 0; > > + > > + if (i915_gem_object_lock_interruptible(obj, NULL)) > > + return 0; > > + > > + if (i915_gem_object_is_lmem(obj)) > > + wakeref = > > +intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm); > > + > > + i915_gem_object_unlock(obj); > > + > > + return wakeref; > > +} > > + > > static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) > > { > > struct vm_area_struct *area = vmf->vma; > > struct ttm_buffer_object *bo = area->vm_private_data; > > struct drm_device *dev = bo->base.dev; > > struct drm_i915_gem_object *obj; > > + intel_wakeref_t wakeref = 0; > > vm_fault_t ret; > > int idx; > > > > @@ -1027,18 +1044,23 @@ static vm_fault_t vm_fault_ttm(struct vm_fault > *vmf) > > if (!obj) > > return VM_FAULT_SIGBUS; > > > > + wakeref = i915_gem_ttm_get_lmem_obj_wakeref(obj); > > We shouldn't drop the lock here (also failing to acquire the lock should be fatal), > since the object can in thoery transition to/from lmem inbetween dropping the > object lock here and re-acquiring it again below, which means we might skip > grabbing the wakeref here, but then later touch the list, if say it moves to lmem. By not releasing the lock there was a deadlock from ttm_bo_vm_reserve(). > > > + > > /* Sanity check that we allow writing into this object */ > > if (unlikely(i915_gem_object_is_readonly(obj) && > > - area->vm_flags & VM_WRITE)) > > - return VM_FAULT_SIGBUS; > > + area->vm_flags & VM_WRITE)) { > > + ret = VM_FAULT_SIGBUS; > > + goto out_rpm; > > + } > > > > ret = ttm_bo_vm_reserve(bo, vmf); > if (ret) > > - return ret; > > + goto out_rpm; > > > > if (obj->mm.madv != I915_MADV_WILLNEED) { > > dma_resv_unlock(bo->base.resv); > > - return VM_FAULT_SIGBUS; > > + ret = VM_FAULT_SIGBUS; > > + goto out_rpm; > > } > > > > if (!i915_ttm_resource_mappable(bo->resource)) { > > @@ -1062,7 +1084,8 @@ static vm_fault_t vm_fault_ttm(struct vm_fault > *vmf) > > if (err) { > > drm_dbg(dev, "Unable to make resource CPU > accessible\n"); > > dma_resv_unlock(bo->base.resv); > > - return VM_FAULT_SIGBUS; > > + ret = VM_FAULT_SIGBUS; > > + goto out_rpm; > > } > > } > > > > @@ -1073,12 +1096,25 @@ static vm_fault_t vm_fault_ttm(struct vm_fault > *vmf) > > } else { > > ret = ttm_bo_vm_dummy_page(vmf, vmf->vma- > >vm_page_prot); > > } > > + > > + /* ttm_bo_vm_reserve() already has dma_resv_lock */ > > + if (!ret && i915_gem_object_is_lmem(obj) && !obj->userfault_count++) > { > > This might increment userfault_count more than once per mapping/object? > Is that intentional? I would have thought that with fault_ttm the > user_fault_count shouldn't ever be > 1 (there is no partial mmap here). I did not get this part, the double addition for the object is possible only when ttm_fault will get called multiple times for an object ? In that case isn't userfault_count would be > 1 ? > > Also it look like ret == VM_FAULT_NOPAGE if all went well. Although it > also returns that if the wait was interrupted, but I don't think that > matters much. > > Maybe we can do something like: > > ret = ttm_bo_vm_reserve(bo..) /* locks the object for us */ > .. > > wakeref = 0; > if (i915_ttm_cpu_maps_iomem(bo->resource)) > wakeref = intel_runtime_pm_get(); > > if (drm_dev_enter(dev, &idx)) { > } else { > } > > if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) > goto out_rpm; > > if (ret == VM_FAULT_NOPAGE && wakeref && !obj->userfault_count) { > obj->userfault_count++; /* protected by wakeref */ > mutex_lock() > list_add(); > mutex_unlock(); > } > > ? Thanks for suggestion, I will implement it. > > AFAICT we are then still missing something for object destruction, to > ensure we remove the object from the list. Otherwise we can destroy the > object, and then at some later point i915_gem_runtime_suspend() runs and > will uaf on the list. I think the trick with GTT mmap is that it will > always grab the wakeref when unbinding the vma (like during object > destruction), and then it can safely remove the object from the list. > Perhaps we will need a similar trick anyway, since destroying the object > will likely require unbinding it, which will mean touching the > page-tables from the CPU, which are in lmem anyway. Do we maybe just > always grab the wakeref for dgpu? What do you think? With input from @rodrigo , we can't get permanent wakref as that will block the d3cold(it will burn the card power). How about deleting the object from the list in __i915_gem_object_free_mmaps() to handle the object destroy case ? If this approach is not scalable then probably we need to think over to get the wakref on dGPU whenever any client is connected. I was also thinking in direct to limit the mmap mapping for lmem object by using a new mmap fake offset to limit the rpm suspend latency due to revoking and re-creation of mmap ? > > Also on second thought it looks like we can't directly call > i915_gem_object_release_mmap_offset() from i915_gem_runtime_suspend(), > without then also holding the object lock for the ttm_mem_io_free(). But > I think it should be OK to just directly call > drm_vma_node_unmap(&bo->base.vma_node, ...) instead. > > Also, do you know if we need something like > CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND here? It is to induced additional delay before actual runtime pm triggers. Yeah it make sense to use that , I missed earlier to incorporate this comment. Thanks, Anshuman Gupta. > > > + mutex_lock(&to_gt(to_i915(obj->base.dev))- > >lmem_userfault_lock); > > + list_add(&obj->userfault_link, &to_gt(to_i915(obj->base.dev))- > >lmem_userfault_list); > > + mutex_unlock(&to_gt(to_i915(obj->base.dev))- > >lmem_userfault_lock); > > + } > > + > > if (ret == VM_FAULT_RETRY && !(vmf->flags & > FAULT_FLAG_RETRY_NOWAIT)) > > - return ret; > > + goto out_rpm; > > > > i915_ttm_adjust_lru(obj); > > > > dma_resv_unlock(bo->base.resv); > > + > > +out_rpm: > > + if (wakeref) > > + intel_runtime_pm_put(&to_i915(obj->base.dev)->runtime_pm, > wakeref); > > + > > return ret; > > } > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > b/drivers/gpu/drm/i915/gt/intel_gt.c > > index e4bac2431e41..63616ea198ca 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > > @@ -39,6 +39,8 @@ static void __intel_gt_init_early(struct intel_gt *gt) > > { > > spin_lock_init(>->irq_lock); > > > > + INIT_LIST_HEAD(>->lmem_userfault_list); > > + mutex_init(>->lmem_userfault_lock); > > INIT_LIST_HEAD(>->closed_vma); > > spin_lock_init(>->closed_lock); > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h > b/drivers/gpu/drm/i915/gt/intel_gt_types.h > > index 4d56f7d5a3be..330e7531cf22 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h > > @@ -132,6 +132,9 @@ struct intel_gt { > > struct intel_wakeref wakeref; > > atomic_t user_wakeref; > > > > + struct mutex lmem_userfault_lock; /* Protects access to usefault list */ > > + struct list_head lmem_userfault_list; > > + > > struct list_head closed_vma; > > spinlock_t closed_lock; /* guards the list of closed_vma */ > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > b/drivers/gpu/drm/i915/i915_gem.c > > index 702e5b89be22..288dc7e231dc 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -842,6 +842,14 @@ void i915_gem_runtime_suspend(struct > drm_i915_private *i915) > > &to_gt(i915)->ggtt->userfault_list, > userfault_link) > > __i915_gem_object_release_mmap_gtt(obj); > > > > + list_for_each_entry_safe(obj, on, > > + &to_gt(i915)->lmem_userfault_list, > userfault_link) { > > + i915_gem_object_release_mmap_offset(obj); > > + > > + if (!--obj->userfault_count) > > + list_del(&obj->userfault_link); > > + } > > + > > /* > > * The fence will be lost when the device powers down. If any were > > * in use by hardware (i.e. they are pinned), we should not be powering ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend 2022-08-29 11:15 ` Gupta, Anshuman @ 2022-08-30 13:39 ` Matthew Auld 2022-08-30 14:02 ` Matthew Auld 0 siblings, 1 reply; 9+ messages in thread From: Matthew Auld @ 2022-08-30 13:39 UTC (permalink / raw) To: Gupta, Anshuman Cc: intel-gfx@lists.freedesktop.org, Vivi, Rodrigo, Auld, Matthew, chris@chris-wilson.co.uk On Mon, 29 Aug 2022 at 12:15, Gupta, Anshuman <anshuman.gupta@intel.com> wrote: > > > > > -----Original Message----- > > From: Auld, Matthew <matthew.auld@intel.com> > Thanks Matt for reviewing this. > > Sent: Friday, August 26, 2022 11:09 PM > > To: Gupta, Anshuman <anshuman.gupta@intel.com>; intel- > > gfx@lists.freedesktop.org > > Cc: joonas.lahtinen@linux.intel.com; Vivi, Rodrigo <rodrigo.vivi@intel.com>; > > Nilawar, Badal <badal.nilawar@intel.com>; chris@chris-wilson.co.uk > > Subject: Re: [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend > > > > On 25/08/2022 11:54, Anshuman Gupta wrote: > > > Release all mmap mapping for all lmem objects which are associated > > > with userfault such that, while pcie function in D3hot, any access to > > > memory mappings will raise a userfault. > > > > > > Runtime resume the dgpu(when gem object lies in lmem). > > > This will transition the dgpu graphics function to D0 state if it was > > > in D3 in order to access the mmap memory mappings. > > > > > > v2: > > > - Squashes the patches. [Matt Auld] > > > - Add adequate locking for lmem_userfault_list addition. [Matt Auld] > > > - Reused obj->userfault_count to avoid double addition. [Matt Auld] > > > - Added i915_gem_object_lock to check > > > i915_gem_object_is_lmem. [Matt Auld] > > > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331 > > > > Just double checking, this is needed for DG1 and DG2, right? Are there any BSpec > > links we can add here? > This is specific to all discrete products with respect to PCIe Spec Section 5.3.1.4.1 > I will add the PCIe specs link here. > > > > > Cc: Matthew Auld <matthew.auld@intel.com> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > > > --- > > > .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 48 ++++++++++++++++--- > > > drivers/gpu/drm/i915/gt/intel_gt.c | 2 + > > > drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++ > > > drivers/gpu/drm/i915/i915_gem.c | 8 ++++ > > > 5 files changed, 57 insertions(+), 7 deletions(-) > > > > > > 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 9f6b14ec189a..40305e2bcd49 100644 > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > > > @@ -298,7 +298,8 @@ struct drm_i915_gem_object { > > > }; > > > > > > /** > > > - * Whether the object is currently in the GGTT mmap. > > > + * Whether the object is currently in the GGTT or any other supported > > > + * fake offset mmap backed by lmem. > > > */ > > > unsigned int userfault_count; > > > struct list_head userfault_link; > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > index 5a5cf332d8a5..6532a634bd20 100644 > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > @@ -1014,12 +1014,29 @@ static void i915_ttm_delayed_free(struct > > drm_i915_gem_object *obj) > > > ttm_bo_put(i915_gem_to_ttm(obj)); > > > } > > > > > > +static intel_wakeref_t > > > +i915_gem_ttm_get_lmem_obj_wakeref(struct drm_i915_gem_object *obj) { > > > + intel_wakeref_t wakeref = 0; > > > + > > > + if (i915_gem_object_lock_interruptible(obj, NULL)) > > > + return 0; > > > + > > > + if (i915_gem_object_is_lmem(obj)) > > > + wakeref = > > > +intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm); > > > + > > > + i915_gem_object_unlock(obj); > > > + > > > + return wakeref; > > > +} > > > + > > > static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) > > > { > > > struct vm_area_struct *area = vmf->vma; > > > struct ttm_buffer_object *bo = area->vm_private_data; > > > struct drm_device *dev = bo->base.dev; > > > struct drm_i915_gem_object *obj; > > > + intel_wakeref_t wakeref = 0; > > > vm_fault_t ret; > > > int idx; > > > > > > @@ -1027,18 +1044,23 @@ static vm_fault_t vm_fault_ttm(struct vm_fault > > *vmf) > > > if (!obj) > > > return VM_FAULT_SIGBUS; > > > > > > + wakeref = i915_gem_ttm_get_lmem_obj_wakeref(obj); > > > > We shouldn't drop the lock here (also failing to acquire the lock should be fatal), > > since the object can in thoery transition to/from lmem inbetween dropping the > > object lock here and re-acquiring it again below, which means we might skip > > grabbing the wakeref here, but then later touch the list, if say it moves to lmem. > By not releasing the lock there was a deadlock from ttm_bo_vm_reserve(). Right, so we should probably move the check under vm_reserve. > > > > > + > > > /* Sanity check that we allow writing into this object */ > > > if (unlikely(i915_gem_object_is_readonly(obj) && > > > - area->vm_flags & VM_WRITE)) > > > - return VM_FAULT_SIGBUS; > > > + area->vm_flags & VM_WRITE)) { > > > + ret = VM_FAULT_SIGBUS; > > > + goto out_rpm; > > > + } > > > > > > ret = ttm_bo_vm_reserve(bo, vmf); > if (ret) > > > - return ret; > > > + goto out_rpm; > > > > > > if (obj->mm.madv != I915_MADV_WILLNEED) { > > > dma_resv_unlock(bo->base.resv); > > > - return VM_FAULT_SIGBUS; > > > + ret = VM_FAULT_SIGBUS; > > > + goto out_rpm; > > > } > > > > > > if (!i915_ttm_resource_mappable(bo->resource)) { > > > @@ -1062,7 +1084,8 @@ static vm_fault_t vm_fault_ttm(struct vm_fault > > *vmf) > > > if (err) { > > > drm_dbg(dev, "Unable to make resource CPU > > accessible\n"); > > > dma_resv_unlock(bo->base.resv); > > > - return VM_FAULT_SIGBUS; > > > + ret = VM_FAULT_SIGBUS; > > > + goto out_rpm; > > > } > > > } > > > > > > @@ -1073,12 +1096,25 @@ static vm_fault_t vm_fault_ttm(struct vm_fault > > *vmf) > > > } else { > > > ret = ttm_bo_vm_dummy_page(vmf, vmf->vma- > > >vm_page_prot); > > > } > > > + > > > + /* ttm_bo_vm_reserve() already has dma_resv_lock */ > > > + if (!ret && i915_gem_object_is_lmem(obj) && !obj->userfault_count++) > > { > > > > This might increment userfault_count more than once per mapping/object? > > Is that intentional? I would have thought that with fault_ttm the > > user_fault_count shouldn't ever be > 1 (there is no partial mmap here). > I did not get this part, the double addition for the object is possible only when ttm_fault will > get called multiple times for an object ? In that case isn't userfault_count would be > 1 ? Right, if it gets mapped and then unmapped multiple times, then userfault_count might be > 1. In i915_gem_runtime_suspend() we only remove it from the list once userfault_count is zero. Just wondering if there is more going on there? Since with ttm_fault we can't partially mmap the object (unlike with GGTT mmap), so there should only be one mapping per object, AFAIK. > > > > > Also it look like ret == VM_FAULT_NOPAGE if all went well. Although it > > also returns that if the wait was interrupted, but I don't think that > > matters much. > > > > Maybe we can do something like: > > > > ret = ttm_bo_vm_reserve(bo..) /* locks the object for us */ > > .. > > > > wakeref = 0; > > if (i915_ttm_cpu_maps_iomem(bo->resource)) > > wakeref = intel_runtime_pm_get(); > > > > if (drm_dev_enter(dev, &idx)) { > > } else { > > } > > > > if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) > > goto out_rpm; > > > > if (ret == VM_FAULT_NOPAGE && wakeref && !obj->userfault_count) { > > obj->userfault_count++; /* protected by wakeref */ > > mutex_lock() > > list_add(); > > mutex_unlock(); > > } > > > > ? > Thanks for suggestion, I will implement it. > > > > AFAICT we are then still missing something for object destruction, to > > ensure we remove the object from the list. Otherwise we can destroy the > > object, and then at some later point i915_gem_runtime_suspend() runs and > > will uaf on the list. I think the trick with GTT mmap is that it will > > always grab the wakeref when unbinding the vma (like during object > > destruction), and then it can safely remove the object from the list. > > Perhaps we will need a similar trick anyway, since destroying the object > > will likely require unbinding it, which will mean touching the > > page-tables from the CPU, which are in lmem anyway. Do we maybe just > > always grab the wakeref for dgpu? What do you think? > With input from @rodrigo , we can't get permanent wakref as that will > block the d3cold(it will burn the card power). I meant just always grabbing during object destruction. > How about deleting the object from the list in __i915_gem_object_free_mmaps() to handle the > object destroy case ? Yeah, something like that. Also note that if there is a bound vma during object destruction, we will need to grab the runtime pm anyway, since that will touch lmem from the CPU with the page-tables. > If this approach is not scalable then probably we need to think over to get the wakref on dGPU > whenever any client is connected. > I was also thinking in direct to limit the mmap mapping for lmem object by using a new mmap fake offset > to limit the rpm suspend latency due to revoking and re-creation of mmap ? Hmm, not sure I follow with the idea of using a new fake offset. Can you share more info? > > > > Also on second thought it looks like we can't directly call > > i915_gem_object_release_mmap_offset() from i915_gem_runtime_suspend(), > > without then also holding the object lock for the ttm_mem_io_free(). But > > I think it should be OK to just directly call > > drm_vma_node_unmap(&bo->base.vma_node, ...) instead. > > > > Also, do you know if we need something like > > CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND here? > It is to induced additional delay before actual runtime pm triggers. > Yeah it make sense to use that , I missed earlier to incorporate this comment. > Thanks, > Anshuman Gupta. > > > > > + mutex_lock(&to_gt(to_i915(obj->base.dev))- > > >lmem_userfault_lock); > > > + list_add(&obj->userfault_link, &to_gt(to_i915(obj->base.dev))- > > >lmem_userfault_list); > > > + mutex_unlock(&to_gt(to_i915(obj->base.dev))- > > >lmem_userfault_lock); > > > + } > > > + > > > if (ret == VM_FAULT_RETRY && !(vmf->flags & > > FAULT_FLAG_RETRY_NOWAIT)) > > > - return ret; > > > + goto out_rpm; > > > > > > i915_ttm_adjust_lru(obj); > > > > > > dma_resv_unlock(bo->base.resv); > > > + > > > +out_rpm: > > > + if (wakeref) > > > + intel_runtime_pm_put(&to_i915(obj->base.dev)->runtime_pm, > > wakeref); > > > + > > > return ret; > > > } > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > > b/drivers/gpu/drm/i915/gt/intel_gt.c > > > index e4bac2431e41..63616ea198ca 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > > > @@ -39,6 +39,8 @@ static void __intel_gt_init_early(struct intel_gt *gt) > > > { > > > spin_lock_init(>->irq_lock); > > > > > > + INIT_LIST_HEAD(>->lmem_userfault_list); > > > + mutex_init(>->lmem_userfault_lock); > > > INIT_LIST_HEAD(>->closed_vma); > > > spin_lock_init(>->closed_lock); > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h > > b/drivers/gpu/drm/i915/gt/intel_gt_types.h > > > index 4d56f7d5a3be..330e7531cf22 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h > > > @@ -132,6 +132,9 @@ struct intel_gt { > > > struct intel_wakeref wakeref; > > > atomic_t user_wakeref; > > > > > > + struct mutex lmem_userfault_lock; /* Protects access to usefault list */ > > > + struct list_head lmem_userfault_list; > > > + > > > struct list_head closed_vma; > > > spinlock_t closed_lock; /* guards the list of closed_vma */ > > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > > index 702e5b89be22..288dc7e231dc 100644 > > > --- a/drivers/gpu/drm/i915/i915_gem.c > > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > > @@ -842,6 +842,14 @@ void i915_gem_runtime_suspend(struct > > drm_i915_private *i915) > > > &to_gt(i915)->ggtt->userfault_list, > > userfault_link) > > > __i915_gem_object_release_mmap_gtt(obj); > > > > > > + list_for_each_entry_safe(obj, on, > > > + &to_gt(i915)->lmem_userfault_list, > > userfault_link) { > > > + i915_gem_object_release_mmap_offset(obj); > > > + > > > + if (!--obj->userfault_count) > > > + list_del(&obj->userfault_link); > > > + } > > > + > > > /* > > > * The fence will be lost when the device powers down. If any were > > > * in use by hardware (i.e. they are pinned), we should not be powering ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend 2022-08-30 13:39 ` Matthew Auld @ 2022-08-30 14:02 ` Matthew Auld 0 siblings, 0 replies; 9+ messages in thread From: Matthew Auld @ 2022-08-30 14:02 UTC (permalink / raw) To: Gupta, Anshuman Cc: intel-gfx@lists.freedesktop.org, Vivi, Rodrigo, Auld, Matthew, chris@chris-wilson.co.uk On Tue, 30 Aug 2022 at 14:39, Matthew Auld <matthew.william.auld@gmail.com> wrote: > > On Mon, 29 Aug 2022 at 12:15, Gupta, Anshuman <anshuman.gupta@intel.com> wrote: > > > > > > > > > -----Original Message----- > > > From: Auld, Matthew <matthew.auld@intel.com> > > Thanks Matt for reviewing this. > > > Sent: Friday, August 26, 2022 11:09 PM > > > To: Gupta, Anshuman <anshuman.gupta@intel.com>; intel- > > > gfx@lists.freedesktop.org > > > Cc: joonas.lahtinen@linux.intel.com; Vivi, Rodrigo <rodrigo.vivi@intel.com>; > > > Nilawar, Badal <badal.nilawar@intel.com>; chris@chris-wilson.co.uk > > > Subject: Re: [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend > > > > > > On 25/08/2022 11:54, Anshuman Gupta wrote: > > > > Release all mmap mapping for all lmem objects which are associated > > > > with userfault such that, while pcie function in D3hot, any access to > > > > memory mappings will raise a userfault. > > > > > > > > Runtime resume the dgpu(when gem object lies in lmem). > > > > This will transition the dgpu graphics function to D0 state if it was > > > > in D3 in order to access the mmap memory mappings. > > > > > > > > v2: > > > > - Squashes the patches. [Matt Auld] > > > > - Add adequate locking for lmem_userfault_list addition. [Matt Auld] > > > > - Reused obj->userfault_count to avoid double addition. [Matt Auld] > > > > - Added i915_gem_object_lock to check > > > > i915_gem_object_is_lmem. [Matt Auld] > > > > > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331 > > > > > > Just double checking, this is needed for DG1 and DG2, right? Are there any BSpec > > > links we can add here? > > This is specific to all discrete products with respect to PCIe Spec Section 5.3.1.4.1 > > I will add the PCIe specs link here. > > > > > > > Cc: Matthew Auld <matthew.auld@intel.com> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > > Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> > > > > --- > > > > .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- > > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 48 ++++++++++++++++--- > > > > drivers/gpu/drm/i915/gt/intel_gt.c | 2 + > > > > drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++ > > > > drivers/gpu/drm/i915/i915_gem.c | 8 ++++ > > > > 5 files changed, 57 insertions(+), 7 deletions(-) > > > > > > > > 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 9f6b14ec189a..40305e2bcd49 100644 > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > > > > @@ -298,7 +298,8 @@ struct drm_i915_gem_object { > > > > }; > > > > > > > > /** > > > > - * Whether the object is currently in the GGTT mmap. > > > > + * Whether the object is currently in the GGTT or any other supported > > > > + * fake offset mmap backed by lmem. > > > > */ > > > > unsigned int userfault_count; > > > > struct list_head userfault_link; > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > > index 5a5cf332d8a5..6532a634bd20 100644 > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > > @@ -1014,12 +1014,29 @@ static void i915_ttm_delayed_free(struct > > > drm_i915_gem_object *obj) > > > > ttm_bo_put(i915_gem_to_ttm(obj)); > > > > } > > > > > > > > +static intel_wakeref_t > > > > +i915_gem_ttm_get_lmem_obj_wakeref(struct drm_i915_gem_object *obj) { > > > > + intel_wakeref_t wakeref = 0; > > > > + > > > > + if (i915_gem_object_lock_interruptible(obj, NULL)) > > > > + return 0; > > > > + > > > > + if (i915_gem_object_is_lmem(obj)) > > > > + wakeref = > > > > +intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm); > > > > + > > > > + i915_gem_object_unlock(obj); > > > > + > > > > + return wakeref; > > > > +} > > > > + > > > > static vm_fault_t vm_fault_ttm(struct vm_fault *vmf) > > > > { > > > > struct vm_area_struct *area = vmf->vma; > > > > struct ttm_buffer_object *bo = area->vm_private_data; > > > > struct drm_device *dev = bo->base.dev; > > > > struct drm_i915_gem_object *obj; > > > > + intel_wakeref_t wakeref = 0; > > > > vm_fault_t ret; > > > > int idx; > > > > > > > > @@ -1027,18 +1044,23 @@ static vm_fault_t vm_fault_ttm(struct vm_fault > > > *vmf) > > > > if (!obj) > > > > return VM_FAULT_SIGBUS; > > > > > > > > + wakeref = i915_gem_ttm_get_lmem_obj_wakeref(obj); > > > > > > We shouldn't drop the lock here (also failing to acquire the lock should be fatal), > > > since the object can in thoery transition to/from lmem inbetween dropping the > > > object lock here and re-acquiring it again below, which means we might skip > > > grabbing the wakeref here, but then later touch the list, if say it moves to lmem. > > By not releasing the lock there was a deadlock from ttm_bo_vm_reserve(). > > Right, so we should probably move the check under vm_reserve. > > > > > > > > + > > > > /* Sanity check that we allow writing into this object */ > > > > if (unlikely(i915_gem_object_is_readonly(obj) && > > > > - area->vm_flags & VM_WRITE)) > > > > - return VM_FAULT_SIGBUS; > > > > + area->vm_flags & VM_WRITE)) { > > > > + ret = VM_FAULT_SIGBUS; > > > > + goto out_rpm; > > > > + } > > > > > > > > ret = ttm_bo_vm_reserve(bo, vmf); > if (ret) > > > > - return ret; > > > > + goto out_rpm; > > > > > > > > if (obj->mm.madv != I915_MADV_WILLNEED) { > > > > dma_resv_unlock(bo->base.resv); > > > > - return VM_FAULT_SIGBUS; > > > > + ret = VM_FAULT_SIGBUS; > > > > + goto out_rpm; > > > > } > > > > > > > > if (!i915_ttm_resource_mappable(bo->resource)) { > > > > @@ -1062,7 +1084,8 @@ static vm_fault_t vm_fault_ttm(struct vm_fault > > > *vmf) > > > > if (err) { > > > > drm_dbg(dev, "Unable to make resource CPU > > > accessible\n"); > > > > dma_resv_unlock(bo->base.resv); > > > > - return VM_FAULT_SIGBUS; > > > > + ret = VM_FAULT_SIGBUS; > > > > + goto out_rpm; > > > > } > > > > } > > > > > > > > @@ -1073,12 +1096,25 @@ static vm_fault_t vm_fault_ttm(struct vm_fault > > > *vmf) > > > > } else { > > > > ret = ttm_bo_vm_dummy_page(vmf, vmf->vma- > > > >vm_page_prot); > > > > } > > > > + > > > > + /* ttm_bo_vm_reserve() already has dma_resv_lock */ > > > > + if (!ret && i915_gem_object_is_lmem(obj) && !obj->userfault_count++) > > > { > > > > > > This might increment userfault_count more than once per mapping/object? > > > Is that intentional? I would have thought that with fault_ttm the > > > user_fault_count shouldn't ever be > 1 (there is no partial mmap here). > > I did not get this part, the double addition for the object is possible only when ttm_fault will > > get called multiple times for an object ? In that case isn't userfault_count would be > 1 ? > > Right, if it gets mapped and then unmapped multiple times, then > userfault_count might be > 1. In i915_gem_runtime_suspend() we only > remove it from the list once userfault_count > is zero. Just wondering if there is more going on there? Since with > ttm_fault we can't partially mmap the object (unlike with GGTT mmap), > so there should only be one mapping per object, AFAIK. Oh, that's actually not true it seems. It looks like it might only fault some of the pages, as per TTM_BO_VM_NUM_PREFAULT. Although still not sure why we need userfault_count for lmem fault? Or maybe just always set it to one or zero? > > > > > > > > > Also it look like ret == VM_FAULT_NOPAGE if all went well. Although it > > > also returns that if the wait was interrupted, but I don't think that > > > matters much. > > > > > > Maybe we can do something like: > > > > > > ret = ttm_bo_vm_reserve(bo..) /* locks the object for us */ > > > .. > > > > > > wakeref = 0; > > > if (i915_ttm_cpu_maps_iomem(bo->resource)) > > > wakeref = intel_runtime_pm_get(); > > > > > > if (drm_dev_enter(dev, &idx)) { > > > } else { > > > } > > > > > > if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) > > > goto out_rpm; > > > > > > if (ret == VM_FAULT_NOPAGE && wakeref && !obj->userfault_count) { > > > obj->userfault_count++; /* protected by wakeref */ > > > mutex_lock() > > > list_add(); > > > mutex_unlock(); > > > } > > > > > > ? > > Thanks for suggestion, I will implement it. > > > > > > AFAICT we are then still missing something for object destruction, to > > > ensure we remove the object from the list. Otherwise we can destroy the > > > object, and then at some later point i915_gem_runtime_suspend() runs and > > > will uaf on the list. I think the trick with GTT mmap is that it will > > > always grab the wakeref when unbinding the vma (like during object > > > destruction), and then it can safely remove the object from the list. > > > Perhaps we will need a similar trick anyway, since destroying the object > > > will likely require unbinding it, which will mean touching the > > > page-tables from the CPU, which are in lmem anyway. Do we maybe just > > > always grab the wakeref for dgpu? What do you think? > > With input from @rodrigo , we can't get permanent wakref as that will > > block the d3cold(it will burn the card power). > > I meant just always grabbing during object destruction. > > > How about deleting the object from the list in __i915_gem_object_free_mmaps() to handle the > > object destroy case ? > > Yeah, something like that. Also note that if there is a bound vma > during object destruction, we will need to grab the runtime pm anyway, > since that will touch lmem from the CPU with the page-tables. > > > If this approach is not scalable then probably we need to think over to get the wakref on dGPU > > whenever any client is connected. > > I was also thinking in direct to limit the mmap mapping for lmem object by using a new mmap fake offset > > to limit the rpm suspend latency due to revoking and re-creation of mmap ? > > Hmm, not sure I follow with the idea of using a new fake offset. Can > you share more info? > > > > > > > Also on second thought it looks like we can't directly call > > > i915_gem_object_release_mmap_offset() from i915_gem_runtime_suspend(), > > > without then also holding the object lock for the ttm_mem_io_free(). But > > > I think it should be OK to just directly call > > > drm_vma_node_unmap(&bo->base.vma_node, ...) instead. > > > > > > Also, do you know if we need something like > > > CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND here? > > It is to induced additional delay before actual runtime pm triggers. > > Yeah it make sense to use that , I missed earlier to incorporate this comment. > > Thanks, > > Anshuman Gupta. > > > > > > > + mutex_lock(&to_gt(to_i915(obj->base.dev))- > > > >lmem_userfault_lock); > > > > + list_add(&obj->userfault_link, &to_gt(to_i915(obj->base.dev))- > > > >lmem_userfault_list); > > > > + mutex_unlock(&to_gt(to_i915(obj->base.dev))- > > > >lmem_userfault_lock); > > > > + } > > > > + > > > > if (ret == VM_FAULT_RETRY && !(vmf->flags & > > > FAULT_FLAG_RETRY_NOWAIT)) > > > > - return ret; > > > > + goto out_rpm; > > > > > > > > i915_ttm_adjust_lru(obj); > > > > > > > > dma_resv_unlock(bo->base.resv); > > > > + > > > > +out_rpm: > > > > + if (wakeref) > > > > + intel_runtime_pm_put(&to_i915(obj->base.dev)->runtime_pm, > > > wakeref); > > > > + > > > > return ret; > > > > } > > > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > > > b/drivers/gpu/drm/i915/gt/intel_gt.c > > > > index e4bac2431e41..63616ea198ca 100644 > > > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > > > > @@ -39,6 +39,8 @@ static void __intel_gt_init_early(struct intel_gt *gt) > > > > { > > > > spin_lock_init(>->irq_lock); > > > > > > > > + INIT_LIST_HEAD(>->lmem_userfault_list); > > > > + mutex_init(>->lmem_userfault_lock); > > > > INIT_LIST_HEAD(>->closed_vma); > > > > spin_lock_init(>->closed_lock); > > > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h > > > b/drivers/gpu/drm/i915/gt/intel_gt_types.h > > > > index 4d56f7d5a3be..330e7531cf22 100644 > > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h > > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h > > > > @@ -132,6 +132,9 @@ struct intel_gt { > > > > struct intel_wakeref wakeref; > > > > atomic_t user_wakeref; > > > > > > > > + struct mutex lmem_userfault_lock; /* Protects access to usefault list */ > > > > + struct list_head lmem_userfault_list; > > > > + > > > > struct list_head closed_vma; > > > > spinlock_t closed_lock; /* guards the list of closed_vma */ > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > > b/drivers/gpu/drm/i915/i915_gem.c > > > > index 702e5b89be22..288dc7e231dc 100644 > > > > --- a/drivers/gpu/drm/i915/i915_gem.c > > > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > > > @@ -842,6 +842,14 @@ void i915_gem_runtime_suspend(struct > > > drm_i915_private *i915) > > > > &to_gt(i915)->ggtt->userfault_list, > > > userfault_link) > > > > __i915_gem_object_release_mmap_gtt(obj); > > > > > > > > + list_for_each_entry_safe(obj, on, > > > > + &to_gt(i915)->lmem_userfault_list, > > > userfault_link) { > > > > + i915_gem_object_release_mmap_offset(obj); > > > > + > > > > + if (!--obj->userfault_count) > > > > + list_del(&obj->userfault_link); > > > > + } > > > > + > > > > /* > > > > * The fence will be lost when the device powers down. If any were > > > > * in use by hardware (i.e. they are pinned), we should not be powering ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for DGFX mmap with rpm (rev2) 2022-08-25 10:54 [Intel-gfx] [PATCH 0/1] DGFX mmap with rpm Anshuman Gupta 2022-08-25 10:54 ` [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend Anshuman Gupta @ 2022-08-25 12:27 ` Patchwork 2022-08-25 12:55 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-08-29 17:57 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork 3 siblings, 0 replies; 9+ messages in thread From: Patchwork @ 2022-08-25 12:27 UTC (permalink / raw) To: Anshuman Gupta; +Cc: intel-gfx == Series Details == Series: DGFX mmap with rpm (rev2) URL : https://patchwork.freedesktop.org/series/107400/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for DGFX mmap with rpm (rev2) 2022-08-25 10:54 [Intel-gfx] [PATCH 0/1] DGFX mmap with rpm Anshuman Gupta 2022-08-25 10:54 ` [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend Anshuman Gupta 2022-08-25 12:27 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for DGFX mmap with rpm (rev2) Patchwork @ 2022-08-25 12:55 ` Patchwork 2022-08-29 17:57 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork 3 siblings, 0 replies; 9+ messages in thread From: Patchwork @ 2022-08-25 12:55 UTC (permalink / raw) To: Anshuman Gupta; +Cc: intel-gfx [-- Attachment #1: Type: text/plain, Size: 3661 bytes --] == Series Details == Series: DGFX mmap with rpm (rev2) URL : https://patchwork.freedesktop.org/series/107400/ State : success == Summary == CI Bug Log - changes from CI_DRM_12024 -> Patchwork_107400v2 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/index.html Participating hosts (35 -> 35) ------------------------------ No changes in participating hosts Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_107400v2: ### IGT changes ### #### Suppressed #### The following results come from untrusted machines, tests, or statuses. They do not affect the overall result. * igt@i915_selftest@live@gt_heartbeat: - {bat-dg2-10}: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/bat-dg2-10/igt@i915_selftest@live@gt_heartbeat.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/bat-dg2-10/igt@i915_selftest@live@gt_heartbeat.html Known issues ------------ Here are the changes found in Patchwork_107400v2 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@i915_selftest@live@hangcheck: - fi-hsw-4770: [PASS][3] -> [INCOMPLETE][4] ([i915#4785]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions: - fi-bsw-kefka: [PASS][5] -> [FAIL][6] ([i915#6298]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions.html * igt@runner@aborted: - fi-hsw-4770: NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#4312] / [i915#5594] / [i915#6246]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/fi-hsw-4770/igt@runner@aborted.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785 [i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594 [i915#6246]: https://gitlab.freedesktop.org/drm/intel/issues/6246 [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257 [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298 [i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380 Build changes ------------- * Linux: CI_DRM_12024 -> Patchwork_107400v2 CI-20190529: 20190529 CI_DRM_12024: 656b7e74f416705f11953d30cda518a98f18ba2e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6636: 1298b5f0e1b3e010657ffba41d2e775fab028e08 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_107400v2: 656b7e74f416705f11953d30cda518a98f18ba2e @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 0da1a5ee767f drm/i915/dgfx: Release mmap on rpm suspend == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/index.html [-- Attachment #2: Type: text/html, Size: 4149 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for DGFX mmap with rpm (rev2) 2022-08-25 10:54 [Intel-gfx] [PATCH 0/1] DGFX mmap with rpm Anshuman Gupta ` (2 preceding siblings ...) 2022-08-25 12:55 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork @ 2022-08-29 17:57 ` Patchwork 3 siblings, 0 replies; 9+ messages in thread From: Patchwork @ 2022-08-29 17:57 UTC (permalink / raw) To: Gupta, Anshuman; +Cc: intel-gfx [-- Attachment #1: Type: text/plain, Size: 24825 bytes --] == Series Details == Series: DGFX mmap with rpm (rev2) URL : https://patchwork.freedesktop.org/series/107400/ State : success == Summary == CI Bug Log - changes from CI_DRM_12024_full -> Patchwork_107400v2_full ==================================================== Summary ------- **SUCCESS** No regressions found. Participating hosts (11 -> 11) ------------------------------ No changes in participating hosts Known issues ------------ Here are the changes found in Patchwork_107400v2_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_exec_balancer@parallel-bb-first: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#4525]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb2/igt@gem_exec_balancer@parallel-bb-first.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb8/igt@gem_exec_balancer@parallel-bb-first.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-tglb6/igt@gem_exec_fair@basic-none-vip@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-tglb7/igt@gem_exec_fair@basic-none-vip@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb1/igt@gem_exec_fair@basic-none@vcs1.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl4/igt@gem_exec_fair@basic-pace@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl7/igt@gem_exec_fair@basic-pace@rcs0.html - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2876]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-tglb6/igt@gem_exec_fair@basic-pace@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-tglb3/igt@gem_exec_fair@basic-pace@rcs0.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-kbl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl1/igt@gem_lmem_swapping@verify-random-ccs.html * igt@gem_userptr_blits@input-checking: - shard-glk: NOTRUN -> [DMESG-WARN][11] ([i915#4991]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk7/igt@gem_userptr_blits@input-checking.html * igt@i915_pm_rpm@dpms-lpsp: - shard-kbl: NOTRUN -> [SKIP][12] ([fdo#109271]) +27 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl7/igt@i915_pm_rpm@dpms-lpsp.html * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - shard-snb: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-snb2/igt@kms_big_fb@x-tiled-64bpp-rotate-0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-snb2/igt@kms_big_fb@x-tiled-64bpp-rotate-0.html * igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3886]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl8/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc: - shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl7/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs: - shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk7/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@dp-edid-change-during-suspend: - shard-glk: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +4 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk7/igt@kms_chamelium@dp-edid-change-during-suspend.html * igt@kms_chamelium@hdmi-mode-timings: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl7/igt@kms_chamelium@hdmi-mode-timings.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][20] -> [FAIL][21] ([i915#2122]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-glk6/igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@ab-hdmi-a1-hdmi-a2.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk2/igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][22] -> [DMESG-WARN][23] ([i915#180]) +1 similar issue [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-iclb: NOTRUN -> [INCOMPLETE][24] ([i915#6598]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb5/igt@kms_flip@flip-vs-suspend@a-edp1.html * igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-32bpp-yftile-downscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][25] ([i915#2672]) +7 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb8/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-32bpp-yftile-downscaling@pipe-a-valid-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][26] ([i915#3555]) [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling@pipe-a-default-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling@pipe-a-valid-mode: - shard-iclb: NOTRUN -> [SKIP][27] ([i915#2672] / [i915#3555]) [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb8/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling@pipe-a-valid-mode.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen: - shard-apl: NOTRUN -> [SKIP][28] ([fdo#109271]) +13 similar issues [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl8/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen.html * igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes: - shard-glk: NOTRUN -> [INCOMPLETE][29] ([i915#6598]) [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk3/igt@kms_plane@plane-panning-bottom-right-suspend@pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb: - shard-glk: NOTRUN -> [FAIL][30] ([i915#265]) [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk7/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html * igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1: - shard-iclb: [PASS][31] -> [SKIP][32] ([i915#5235]) +2 similar issues [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb3/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb2/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1.html * igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-hdmi-a-1: - shard-glk: NOTRUN -> [SKIP][33] ([fdo#109271]) +57 similar issues [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk3/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-hdmi-a-1.html * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area: - shard-kbl: NOTRUN -> [SKIP][34] ([fdo#109271] / [i915#658]) [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl1/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area.html * igt@kms_psr@psr2_cursor_blt: - shard-iclb: [PASS][35] -> [SKIP][36] ([fdo#109441]) +3 similar issues [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb1/igt@kms_psr@psr2_cursor_blt.html * igt@kms_writeback@writeback-fb-id: - shard-apl: NOTRUN -> [SKIP][37] ([fdo#109271] / [i915#2437]) [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl8/igt@kms_writeback@writeback-fb-id.html * igt@kms_writeback@writeback-invalid-parameters: - shard-kbl: NOTRUN -> [SKIP][38] ([fdo#109271] / [i915#2437]) [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl7/igt@kms_writeback@writeback-invalid-parameters.html * igt@runner@aborted: - shard-glk: NOTRUN -> [FAIL][39] ([i915#3002] / [i915#4312] / [i915#5257] / [i915#6599]) [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk7/igt@runner@aborted.html * igt@sysfs_clients@create: - shard-glk: NOTRUN -> [SKIP][40] ([fdo#109271] / [i915#2994]) [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk7/igt@sysfs_clients@create.html #### Possible fixes #### * igt@gem_busy@close-race: - shard-iclb: [TIMEOUT][41] ([i915#6016]) -> [PASS][42] [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb6/igt@gem_busy@close-race.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb5/igt@gem_busy@close-race.html * igt@gem_exec_balancer@parallel-keep-in-fence: - shard-iclb: [SKIP][43] ([i915#4525]) -> [PASS][44] +2 similar issues [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb8/igt@gem_exec_balancer@parallel-keep-in-fence.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb2/igt@gem_exec_balancer@parallel-keep-in-fence.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [FAIL][45] ([i915#2842]) -> [PASS][46] [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-apl3/igt@gem_exec_fair@basic-none-solo@rcs0.html [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl3/igt@gem_exec_fair@basic-none-solo@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [FAIL][47] ([i915#2842]) -> [PASS][48] [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-glk7/igt@gem_exec_fair@basic-pace-share@rcs0.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk7/igt@gem_exec_fair@basic-pace-share@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-kbl: [FAIL][49] ([i915#2842]) -> [PASS][50] [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl4/igt@gem_exec_fair@basic-pace@vcs0.html [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl7/igt@gem_exec_fair@basic-pace@vcs0.html * igt@gen9_exec_parse@allowed-single: - shard-apl: [DMESG-WARN][51] ([i915#5566] / [i915#716]) -> [PASS][52] [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-apl7/igt@gen9_exec_parse@allowed-single.html [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl8/igt@gen9_exec_parse@allowed-single.html * igt@i915_pm_rc6_residency@rc6-idle@bcs0: - shard-kbl: [FAIL][53] -> [PASS][54] [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl6/igt@i915_pm_rc6_residency@rc6-idle@bcs0.html [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl4/igt@i915_pm_rc6_residency@rc6-idle@bcs0.html * igt@kms_big_fb@y-tiled-16bpp-rotate-0: - shard-apl: [DMESG-WARN][55] ([i915#5904] / [i915#62]) -> [PASS][56] +11 similar issues [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-apl6/igt@kms_big_fb@y-tiled-16bpp-rotate-0.html [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl1/igt@kms_big_fb@y-tiled-16bpp-rotate-0.html * igt@kms_cursor_crc@cursor-random@pipe-b-dp-1-64x21: - shard-apl: [DMESG-WARN][57] ([i915#180] / [i915#5904] / [i915#62]) -> [PASS][58] +38 similar issues [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-apl6/igt@kms_cursor_crc@cursor-random@pipe-b-dp-1-64x21.html [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl1/igt@kms_cursor_crc@cursor-random@pipe-b-dp-1-64x21.html * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size: - shard-glk: [FAIL][59] ([i915#2346]) -> [PASS][60] +1 similar issue [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-glk9/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size.html [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk8/igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size.html * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-xtiled: - shard-apl: [DMESG-FAIL][61] ([i915#62]) -> [PASS][62] +1 similar issue [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-apl6/igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-xtiled.html [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl1/igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-xtiled.html * igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary: - shard-apl: [DMESG-WARN][63] ([i915#62]) -> [PASS][64] +12 similar issues [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-apl6/igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary.html [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl1/igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [DMESG-WARN][65] ([i915#180]) -> [PASS][66] +1 similar issue [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-suspend.html [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-suspend.html * igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1: - shard-kbl: [FAIL][67] ([i915#1188]) -> [PASS][68] +1 similar issue [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl1/igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1.html [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl7/igt@kms_hdr@bpc-switch-dpms@pipe-a-dp-1.html * igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-edp-1: - shard-iclb: [SKIP][69] ([i915#5235]) -> [PASS][70] +2 similar issues [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-edp-1.html [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb8/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-edp-1.html * igt@kms_psr@psr2_sprite_blt: - shard-iclb: [SKIP][71] ([fdo#109441]) -> [PASS][72] +1 similar issue [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb3/igt@kms_psr@psr2_sprite_blt.html [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html #### Warnings #### * igt@gem_eio@unwedge-stress: - shard-tglb: [TIMEOUT][73] ([i915#3063]) -> [FAIL][74] ([i915#5784]) [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-tglb6/igt@gem_eio@unwedge-stress.html [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-tglb3/igt@gem_eio@unwedge-stress.html * igt@kms_big_fb@y-tiled-8bpp-rotate-0: - shard-glk: [FAIL][75] ([i915#5138]) -> [FAIL][76] ([i915#1888] / [i915#5138]) [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-glk2/igt@kms_big_fb@y-tiled-8bpp-rotate-0.html [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-glk3/igt@kms_big_fb@y-tiled-8bpp-rotate-0.html * igt@kms_content_protection@uevent: - shard-apl: [SKIP][77] ([fdo#109271]) -> [FAIL][78] ([i915#2105]) [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-apl6/igt@kms_content_protection@uevent.html [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl1/igt@kms_content_protection@uevent.html * igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf: - shard-iclb: [SKIP][79] ([i915#658]) -> [SKIP][80] ([i915#2920]) [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb3/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf.html [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb2/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf.html * igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf: - shard-iclb: [SKIP][81] ([i915#2920]) -> [SKIP][82] ([i915#658]) [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb2/igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf.html [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb1/igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-sf.html * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area: - shard-iclb: [SKIP][83] ([i915#2920]) -> [SKIP][84] ([fdo#111068] / [i915#658]) [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-iclb2/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-iclb8/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html * igt@runner@aborted: - shard-apl: ([FAIL][85], [FAIL][86]) ([fdo#109271] / [i915#3002] / [i915#4312] / [i915#5257] / [i915#6599]) -> [FAIL][87] ([i915#3002] / [i915#4312] / [i915#5257] / [i915#6599]) [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-apl2/igt@runner@aborted.html [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-apl7/igt@runner@aborted.html [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-apl6/igt@runner@aborted.html - shard-kbl: ([FAIL][88], [FAIL][89], [FAIL][90], [FAIL][91], [FAIL][92]) ([fdo#109271] / [i915#180] / [i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][93], [FAIL][94], [FAIL][95], [FAIL][96]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#5257]) [88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl1/igt@runner@aborted.html [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl1/igt@runner@aborted.html [90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl1/igt@runner@aborted.html [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl1/igt@runner@aborted.html [92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/shard-kbl1/igt@runner@aborted.html [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl4/igt@runner@aborted.html [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl1/igt@runner@aborted.html [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl1/igt@runner@aborted.html [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/shard-kbl4/igt@runner@aborted.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274 [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280 [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291 [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441 [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068 [fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614 [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1063]: https://gitlab.freedesktop.org/drm/intel/issues/1063 [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188 [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#2105]: https://gitlab.freedesktop.org/drm/intel/issues/2105 [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122 [i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346 [i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437 [i915#2530]: https://gitlab.freedesktop.org/drm/intel/issues/2530 [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265 [i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672 [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842 [i915#2876]: https://gitlab.freedesktop.org/drm/intel/issues/2876 [i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920 [i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994 [i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002 [i915#3063]: https://gitlab.freedesktop.org/drm/intel/issues/3063 [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555 [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637 [i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689 [i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886 [i915#3989]: https://gitlab.freedesktop.org/drm/intel/issues/3989 [i915#426]: https://gitlab.freedesktop.org/drm/intel/issues/426 [i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525 [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#4991]: https://gitlab.freedesktop.org/drm/intel/issues/4991 [i915#5138]: https://gitlab.freedesktop.org/drm/intel/issues/5138 [i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176 [i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235 [i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257 [i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286 [i915#5289]: https://gitlab.freedesktop.org/drm/intel/issues/5289 [i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566 [i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784 [i915#5904]: https://gitlab.freedesktop.org/drm/intel/issues/5904 [i915#6016]: https://gitlab.freedesktop.org/drm/intel/issues/6016 [i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#6335]: https://gitlab.freedesktop.org/drm/intel/issues/6335 [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658 [i915#6598]: https://gitlab.freedesktop.org/drm/intel/issues/6598 [i915#6599]: https://gitlab.freedesktop.org/drm/intel/issues/6599 [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716 Build changes ------------- * Linux: CI_DRM_12024 -> Patchwork_107400v2 CI-20190529: 20190529 CI_DRM_12024: 656b7e74f416705f11953d30cda518a98f18ba2e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6636: 1298b5f0e1b3e010657ffba41d2e775fab028e08 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_107400v2: 656b7e74f416705f11953d30cda518a98f18ba2e @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/index.html [-- Attachment #2: Type: text/html, Size: 29694 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-08-30 14:03 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-08-25 10:54 [Intel-gfx] [PATCH 0/1] DGFX mmap with rpm Anshuman Gupta 2022-08-25 10:54 ` [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend Anshuman Gupta 2022-08-26 17:38 ` Matthew Auld 2022-08-29 11:15 ` Gupta, Anshuman 2022-08-30 13:39 ` Matthew Auld 2022-08-30 14:02 ` Matthew Auld 2022-08-25 12:27 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for DGFX mmap with rpm (rev2) Patchwork 2022-08-25 12:55 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-08-29 17:57 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox