From: Daniel Charles <daniel.charles@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Daniel Charles <daniel.charles@intel.com>
Subject: [PATCH v2 0/3] drm/xe: add wedged_mode=3 fault inspection
Date: Fri, 6 Nov 2026 14:13:20 -0800 [thread overview]
Message-ID: <20261106221323.1207676-1-daniel.charles@intel.com> (raw)
This series adds wedged_mode=3, a best-effort inspection mode for examining
Xe after a fault without automatically restarting the GTs. An operator can
release inspection through debugfs by choosing to skip or continue into
permanent wedging.
The patches add the inspection framework, preserve pending TLB invalidation
fences while inspection is active, and request inspection for additional
fault paths while coordinating MMIO-enabled RAS reset requests.
Changes in v2:
- Make inspection one-shot after GT stopping or runtime-resume failure,
close the teardown admission window, and handle aborted inspection without
leaving stale TLB pause state.
- Extend the GuC submission timeout guard to recognize inspection startup
before the execution queues are marked wedged.
- Clarify the power-management requirements and that SKIP leaves the GTs
stopped; it does not restore normal operation.
- Document that TLB preservation is not a freeze of mapping activity or new
invalidations. New requests may be canceled and signaled while older
fences remain preserved, and GGTT invalidations may still program MMIO
while CT is disabled. Cancellation signaling does not imply hardware
completion; inspection is not an atomic snapshot.
- Document that preserved fences can block process exit, unbind, or unload,
and that recovery may require a power cycle.
The TLB behavior does not prevent subsequent mapping changes or independent
reset/resume activity during inspection. Holding newly issued invalidation
fences could also block synchronous callers indefinitely, including callers
holding the GGTT mutex. The series documents these limitations rather than
claiming inspection is an atomic hardware snapshot.
Runtime validation of the specific inspection-startup timeout interleaving
remains pending.
Alan Previn (1):
drm/xe/wedge: add fault inspection with debugfs release
Daniel Charles (2):
drm/xe/wedge: preserve pending TLB invalidations during inspection
drm/xe/wedge: request inspection for additional fault paths
drivers/gpu/drm/xe/xe_debugfs.c | 39 +++-
drivers/gpu/drm/xe/xe_device.c | 12 +-
drivers/gpu/drm/xe/xe_gt.c | 17 +-
drivers/gpu/drm/xe/xe_gt.h | 1 +
drivers/gpu/drm/xe/xe_guc.c | 2 +-
drivers/gpu/drm/xe/xe_guc_ads.c | 2 +-
drivers/gpu/drm/xe/xe_guc_capture.c | 2 +-
drivers/gpu/drm/xe/xe_guc_submit.c | 25 +-
drivers/gpu/drm/xe/xe_pagefault.c | 3 +
drivers/gpu/drm/xe/xe_pci.c | 16 +-
drivers/gpu/drm/xe/xe_pci_error.c | 11 +
drivers/gpu/drm/xe/xe_tlb_inval.c | 63 +++++
drivers/gpu/drm/xe/xe_tlb_inval.h | 1 +
drivers/gpu/drm/xe/xe_tlb_inval_types.h | 4 +
drivers/gpu/drm/xe/xe_uc.c | 2 +-
drivers/gpu/drm/xe/xe_wedge.c | 292 ++++++++++++++++++++++--
drivers/gpu/drm/xe/xe_wedge.h | 4 +
drivers/gpu/drm/xe/xe_wedge_types.h | 48 ++++
18 files changed, 512 insertions(+), 32 deletions(-)
--
2.43.0
next reply other threads:[~2026-11-06 22:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 22:13 Daniel Charles [this message]
2026-11-06 22:13 ` [PATCH v2 1/3] drm/xe/wedge: add fault inspection with debugfs release Daniel Charles
2026-11-06 22:59 ` sashiko-bot
2026-11-06 22:13 ` [PATCH v2 2/3] drm/xe/wedge: preserve pending TLB invalidations during inspection Daniel Charles
2026-11-06 22:13 ` [PATCH v2 3/3] drm/xe/wedge: request inspection for additional fault paths Daniel Charles
2026-11-06 22:40 ` ✗ CI.checkpatch: warning for drm/xe: add wedged_mode=3 fault inspection Patchwork
2026-11-06 22:42 ` ✓ CI.KUnit: success " Patchwork
2026-11-06 23:16 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-08 3:36 ` ✗ Xe.CI.FULL: failure " Patchwork
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=20261106221323.1207676-1-daniel.charles@intel.com \
--to=daniel.charles@intel.com \
--cc=intel-xe@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.