From: Arvind Yadav <arvind.yadav@intel.com>
To: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: matthew.brost@intel.com, himal.prasad.ghimiray@intel.com,
thomas.hellstrom@linux.intel.com, rodrigo.vivi@intel.com
Subject: [PATCH v2 08/15] drm/xe: Reuse one dummy page per BO after wedge
Date: Tue, 22 Sep 2026 15:46:53 +0530 [thread overview]
Message-ID: <20260922101721.1583542-9-arvind.yadav@intel.com> (raw)
In-Reply-To: <20260922101721.1583542-1-arvind.yadav@intel.com>
ttm_bo_vm_dummy_page() allocates a page and a managed cleanup action on
every call. These allocations remain until the DRM device is released,
so repeated fallback faults can retain many pages.
Keep one zeroed dummy page in each Xe BO and reuse it when device I/O is
blocked or the device is unplugged. Use cmpxchg() to handle concurrent
faults and free the page when the BO is destroyed.
A per-BO page also prevents writable mappings from different BOs from
sharing data.
Map only the faulting address and return the insertion result directly.
Other addresses fault on demand and reuse the same dummy page.
This avoids walking a potentially large VMA during a single fault.
v2:
- Drop whole-VMA prefaulting and map only the faulting address to avoid
long fault-handler runtimes on large mappings. (Sashiko)
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
---
drivers/gpu/drm/xe/xe_bo.c | 33 +++++++++++++++++++++++++++++++-
drivers/gpu/drm/xe/xe_bo_types.h | 4 ++++
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index b39b07b55f64..7902ce3fe012 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -1890,6 +1890,9 @@ static void xe_ttm_bo_destroy(struct ttm_buffer_object *ttm_bo)
list_del(&bo->vram_userfault_link);
mutex_unlock(&xe->mem_access.vram_userfault.lock);
+ if (bo->wedged_dummy_page)
+ __free_page(bo->wedged_dummy_page);
+
kfree(bo);
}
@@ -2094,6 +2097,32 @@ static vm_fault_t xe_bo_cpu_fault_fastpath(struct vm_fault *vmf, struct xe_devic
return ret;
}
+static vm_fault_t xe_bo_vm_dummy_page(struct vm_fault *vmf, struct xe_bo *bo)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct page *page, *old;
+ unsigned long pfn;
+
+ page = READ_ONCE(bo->wedged_dummy_page);
+ if (!page) {
+ page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!page)
+ return VM_FAULT_OOM;
+
+ old = cmpxchg(&bo->wedged_dummy_page, NULL, page);
+ if (old) {
+ __free_page(page);
+ page = old;
+ }
+ }
+
+ pfn = page_to_pfn(page);
+
+ /* Map other addresses on demand instead of walking the whole VMA. */
+ return vmf_insert_pfn_prot(vma, vmf->address, pfn,
+ vma->vm_page_prot);
+}
+
static vm_fault_t xe_bo_cpu_fault(struct vm_fault *vmf)
{
struct ttm_buffer_object *tbo = vmf->vma->vm_private_data;
@@ -2109,7 +2138,7 @@ static vm_fault_t xe_bo_cpu_fault(struct vm_fault *vmf)
int io_idx;
if (xe_device_io_get(xe, &io_idx))
- return ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot);
+ return xe_bo_vm_dummy_page(vmf, bo);
ret = xe_bo_cpu_fault_fastpath(vmf, xe, bo, needs_rpm);
if (ret != VM_FAULT_RETRY)
@@ -2399,6 +2428,8 @@ struct xe_bo *xe_bo_init_locked(struct xe_device *xe, struct xe_bo *bo,
return bo;
}
+ bo->wedged_dummy_page = NULL;
+
bo->ccs_cleared = false;
bo->tile = tile;
bo->flags = flags;
diff --git a/drivers/gpu/drm/xe/xe_bo_types.h b/drivers/gpu/drm/xe/xe_bo_types.h
index 0eb93052c1d5..8b3823b60cbf 100644
--- a/drivers/gpu/drm/xe/xe_bo_types.h
+++ b/drivers/gpu/drm/xe/xe_bo_types.h
@@ -21,6 +21,7 @@ struct xe_device;
struct xe_mem_pool_node;
struct xe_vm;
struct xe_exec_queue;
+struct page;
#define XE_BO_MAX_PLACEMENTS 3
@@ -114,6 +115,9 @@ struct xe_bo {
/** @vram_userfault_link: Link into @mem_access.vram_userfault.list */
struct list_head vram_userfault_link;
+ /** @wedged_dummy_page: Zeroed page used for faults after device wedge */
+ struct page *wedged_dummy_page;
+
/**
* @min_align: minimum alignment needed for this BO if different
* from default
--
2.43.0
next prev parent reply other threads:[~2026-09-22 10:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 10:16 [PATCH v2 00/15] drm/xe: Isolate wedged devices from hardware access Arvind Yadav
2026-09-22 10:16 ` [PATCH v2 01/15] drm/xe/irq: Always free requested IRQs on uninstall Arvind Yadav
2026-09-22 10:16 ` [PATCH v2 02/15] drm/drv: Export drm_dev_srcu_synchronize() Arvind Yadav
2026-09-22 10:16 ` [PATCH v2 03/15] drm/xe: Separate AER reset state from device wedging Arvind Yadav
2026-09-22 10:16 ` [PATCH v2 04/15] drm/xe: Protect device I/O with DRM device SRCU Arvind Yadav
2026-09-22 10:28 ` sashiko-bot
2026-09-22 10:16 ` [PATCH v2 05/15] drm/xe: Drop queued page faults when device I/O is blocked Arvind Yadav
2026-09-22 10:16 ` [PATCH v2 06/15] drm/xe: Stop VM work " Arvind Yadav
2026-09-22 10:16 ` [PATCH v2 07/15] drm/xe: Send wedged notification from a worker Arvind Yadav
2026-09-22 10:27 ` sashiko-bot
2026-09-22 10:16 ` Arvind Yadav [this message]
2026-09-22 10:16 ` [PATCH v2 09/15] drm/xe: Invalidate existing VRAM mappings on wedge Arvind Yadav
2026-09-22 10:30 ` sashiko-bot
2026-09-22 10:16 ` [PATCH v2 10/15] drm/xe/irq: Protect IRQ state during wedge isolation Arvind Yadav
2026-09-22 10:16 ` [PATCH v2 11/15] drm/xe: Isolate a wedged device before notifying userspace Arvind Yadav
2026-09-22 10:31 ` sashiko-bot
2026-09-22 10:16 ` [PATCH v2 12/15] drm/xe/ttm: Reject VRAM allocations on wedged devices Arvind Yadav
2026-09-22 10:16 ` [PATCH v2 13/15] drm/xe/guc: Skip timeout recovery on a wedged device Arvind Yadav
2026-09-22 10:16 ` [PATCH v2 14/15] drm/xe: Skip PM notifier preparation when device I/O is blocked Arvind Yadav
2026-09-22 10:17 ` [PATCH v2 15/15] drm/xe: Block BO VM access when device I/O is unavailable Arvind Yadav
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260922101721.1583542-9-arvind.yadav@intel.com \
--to=arvind.yadav@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox