[RFC PATCH v3 0/3] drm/xe: Structured RAS error logging infrastructure

[RFC PATCH v3 0/3] drm/xe: Structured RAS error logging infrastructure

[Mallesh Koujalagi]

Today XE logs GPU errors with ad-hoc drm_err()/drm_warn() calls that
have no standard format, making it hard to identify what failed, where
on the GPU it happened, and how to correlate events.

This series adds a lightweight structured logging layer:

- Introduces xe_sig_ids.h (Signature IDs that name each error
  class) and xe_ras_log.c (__xe_ras_log()), which emits every error in
  a fixed format:

    [xe-err] SIG_ID=<id> Severity=<sev> Location=<loc> Errno=<n>
    Message="<msg>"

- Converts the first call site: the open-coded drm_err() in
  xe_device_declare_wedged() is replaced with XE_RAS_WEDGED(), routing
  wedge events through the new common path.

v2:
- Rebase.

v3:
- Add HW SIG IDS details. (Riana)
- Refer "Tile%u" and "GT%u" strings. (Michal Wajdeczko)
- Remov xe_cper_severity_str(). (Michal Wajdeczko/Riana)
- Move __xe_ras_log() function to xe_ras_log.h. (Michal Wajdeczko)
- Make macro function properly.
- Remove *_FIRST and *_LAST macro. (Michal Wajdeczko/Riana)
- Add sig id documents. (Riana)
- Change macro function same prefix as the file.
- Handle __xe_ras_log() function with variable format.
- Update message in xe_ras_log_wedged().

Mallesh Koujalagi (3):
  drm/xe: Add error Signature IDs for RAS logging
  drm/xe: Add RAS logging helpers
  drm/xe: use XE_RAS_WEDGED macro in xe_device_declare_wedged

 drivers/gpu/drm/xe/Makefile     |   1 +
 drivers/gpu/drm/xe/xe_device.c  |  13 ++--
 drivers/gpu/drm/xe/xe_ras_log.c |  63 +++++++++++++++++++
 drivers/gpu/drm/xe/xe_ras_log.h | 108 ++++++++++++++++++++++++++++++++
 drivers/gpu/drm/xe/xe_sig_ids.h |  29 +++++++++
 5 files changed, 208 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/xe/xe_ras_log.c
 create mode 100644 drivers/gpu/drm/xe/xe_ras_log.h
 create mode 100644 drivers/gpu/drm/xe/xe_sig_ids.h

-- 
2.34.1

[RFC PATCH v3 1/3] drm/xe: Add error Signature IDs for RAS logging

[Mallesh Koujalagi]

Every GPU fault needs a stable numeric label so monitoring tools can
identify what went wrong without parsing log text. Add xe_sig_ids.h
which defines those labels, called SIG_IDs.

Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
---
v3:
- Add HW SIG IDS details. (Riana)
---
 drivers/gpu/drm/xe/xe_sig_ids.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 drivers/gpu/drm/xe/xe_sig_ids.h

diff --git a/drivers/gpu/drm/xe/xe_sig_ids.h b/drivers/gpu/drm/xe/xe_sig_ids.h
new file mode 100644
index 000000000000..7badd0d7ad72
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_sig_ids.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2026 Intel Corporation
+ */
+
+#ifndef _XE_SIG_IDS_H_
+#define _XE_SIG_IDS_H_
+
+/*
+ * Driver SIG_IDs
+ */
+#define XE_SIG_PROBE			1  /* FATAL: probe failed */
+#define XE_SIG_WEDGED			2  /* FATAL: device wedged */
+#define XE_SIG_SURVIVABILITY		3  /* FATAL: survivability mode */
+#define XE_SIG_FW			4  /* RECOVERABLE: GuC/HuC/UC/GSC/CSC/PCODE */
+#define XE_SIG_GT_TDR			5  /* RECOVERABLE: engine hang / reset */
+#define XE_SIG_MEM_FAULT		6  /* RECOVERABLE: VM bind, page fault, GTT */
+#define XE_SIG_IO_BUS			7  /* RECOVERABLE: runtime PCIe/IOMMU/MMIO */
+
+/*
+ * HW SIG_IDs
+ */
+#define XE_SIG_HW_DEVICE_MEMORY		8  /* Device memory errors (e.g. ECC) */
+#define XE_SIG_HW_CORE_COMPUTE		9  /* Compute/shader core errors */
+#define XE_SIG_HW_PCIE			10 /* PCIe interface errors */
+#define XE_SIG_HW_FABRIC		11 /* On-package fabric errors */
+#define XE_SIG_HW_SOC_INTERNAL		12 /* SoC-internal errors */
+
+#endif /* _XE_SIG_IDS_H_ */
-- 
2.34.1

[RFC PATCH v3 2/3] drm/xe: Add RAS logging helpers

[Mallesh Koujalagi]

Add xe_ras_log.c and xe_ras_log.h so the driver can report
faults in a structured, machine-readable way.

The core is __xe_ras_log(), which emits a single log line with:
SIG_ID, severity, location (device or tile/GT), errno, and message.
Fatal faults go to drm_err(); recoverable ones to drm_warn().

Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
---
v3:
- Refer "Tile%u" and "GT%u" strings. (Michal Wajdeczko)
- Remov xe_cper_severity_str(). (Michal Wajdeczko/Riana)
- Move __xe_ras_log() function to xe_ras_log.h. (Michal Wajdeczko)
- Make macro function properly.
- Remove *_FIRST and *_LAST macro. (Michal Wajdeczko/Riana)
- Add sig id documents. (Riana)
- Change macro function same prefix as the file.
- Handle __xe_ras_log() function with variable format.
---
 drivers/gpu/drm/xe/Makefile     |   1 +
 drivers/gpu/drm/xe/xe_ras_log.c |  63 +++++++++++++++++++
 drivers/gpu/drm/xe/xe_ras_log.h | 108 ++++++++++++++++++++++++++++++++
 3 files changed, 172 insertions(+)
 create mode 100644 drivers/gpu/drm/xe/xe_ras_log.c
 create mode 100644 drivers/gpu/drm/xe/xe_ras_log.h

diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index 8e7b146880f4..607c9b099d03 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -114,6 +114,7 @@ xe-y += xe_bb.o \
 	xe_query.o \
 	xe_range_fence.o \
 	xe_ras.o \
+	xe_ras_log.o \
 	xe_reg_sr.o \
 	xe_reg_whitelist.o \
 	xe_ring_ops.o \
diff --git a/drivers/gpu/drm/xe/xe_ras_log.c b/drivers/gpu/drm/xe/xe_ras_log.c
new file mode 100644
index 000000000000..0e836ef5dcf6
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_ras_log.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2026 Intel Corporation
+ */
+
+#include <drm/drm_print.h>
+
+#include "xe_device.h"
+#include "xe_gt.h"
+#include "xe_ras_log.h"
+
+/**
+ * __xe_ras_log - Emit a structured RAS log entry
+ * @xe: xe device instance
+ * @gt: GT instance where the error occurred, or NULL if device-wide
+ * @sig_id: signature ID from xe_sig_ids.h identifying the error class
+ * @cper_sev: CPER severity (one of CPER_SEV_FATAL, CPER_SEV_RECOVERABLE, etc.)
+ * @errno_val: negative errno describing the error condition
+ * @fmt: printf-style format string
+ * @...: format arguments
+ *
+ * Formats the message and emits a kernel log line via drm_err() for fatal
+ * events or drm_warn() for all others. CPER record generation and hex dump
+ * are planned as follow-ups.
+ *
+ * Format:
+ *   [xe-err] SIG_ID = <id> Severity = <sev> Location = <loc> Errno = <n> Message = "<msg>"
+ */
+__printf(6, 7)
+void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
+		  u16 sig_id, u32 cper_sev, int errno_val,
+		  const char *fmt, ...)
+{
+	char loc[32];
+	struct va_format vaf;
+	va_list ap;
+
+	if (gt)
+		snprintf(loc, sizeof(loc), "tile%u/gt%u",
+			 gt->tile->id, gt->info.id);
+	else
+		snprintf(loc, sizeof(loc), "device");
+
+	va_start(ap, fmt);
+	vaf.fmt = fmt;
+	vaf.va = &ap;
+
+	if (cper_sev == CPER_SEV_FATAL)
+		drm_err(&xe->drm,
+			"[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
+			sig_id, cper_severity_str(cper_sev), loc,
+			errno_val, &vaf);
+	else
+		drm_warn(&xe->drm,
+			 "[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
+			 sig_id, cper_severity_str(cper_sev), loc,
+			 errno_val, &vaf);
+
+	va_end(ap);
+
+	/* TODO: Add CPER record driver handler */
+	/* TODO: Add RAS dump cper hex handler */
+}
diff --git a/drivers/gpu/drm/xe/xe_ras_log.h b/drivers/gpu/drm/xe/xe_ras_log.h
new file mode 100644
index 000000000000..08318dea75a9
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_ras_log.h
@@ -0,0 +1,108 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2026 Intel Corporation
+ */
+
+#ifndef _XE_RAS_LOG_H_
+#define _XE_RAS_LOG_H_
+
+#include <linux/cper.h>
+
+#include "xe_sig_ids.h"
+
+struct xe_device;
+struct xe_gt;
+
+/**
+ * DOC: RAS structured logging and SIG_IDs
+ *
+ * What this file is for
+ * ---------------------
+ * Use the xe_ras_log_*() macros to report faults in a
+ * machine-readable way.
+ *
+ * What is a SIG_ID?
+ * -----------------
+ * A SIG_ID (defined in xe_sig_ids.h) is a stable numeric error class.
+ * It tells tooling what kind of fault happened, independent of message text.
+ *
+ * Driver SIG_ID classes:
+ *   XE_SIG_PROBE         - probe/init failure
+ *   XE_SIG_WEDGED        - device unrecoverable
+ *   XE_SIG_SURVIVABILITY - degraded/safe mode
+ *   XE_SIG_FW            - firmware fault (GuC/HuC/GSC/CSC/PCODE)
+ *   XE_SIG_GT_TDR        - engine hang or GT reset (TDR)
+ *   XE_SIG_MEM_FAULT     - VM/page-fault/GTT error
+ *   XE_SIG_IO_BUS        - PCIe/IOMMU/MMIO bus error
+ *
+ * HW SIG_ID classes are hardware-defined categories, reported by firmware via
+ * CPER records (for example XE_SIG_HW_DEVICE_MEMORY). Driver code does not
+ * emit HW SIG_IDs directly.
+ *   XE_SIG_HW_DEVICE_MEMORY  - device memory errors (e.g. ECC)
+ *   XE_SIG_HW_CORE_COMPUTE   - compute/shader core errors
+ *   XE_SIG_HW_PCIE           - PCIe interface errors
+ *   XE_SIG_HW_FABRIC         - on-package fabric errors
+ *   XE_SIG_HW_SOC_INTERNAL   - SoC-internal errors
+ *
+ * Why this exists
+ * ---------------
+ * SIG_IDs let RAS tools parse logs reliably, correlate CPER events, and apply
+ * policy/thresholding without depending on fragile string matching.
+ *
+ * When to use xe_ras_log_*()
+ * --------------------------
+ * Use these macros when the event is:
+ *   1) a real hardware/firmware fault,
+ *   2) relevant to production monitoring, and
+ *   3) clearly mapped to one SIG_ID class.
+ *
+ * Do not use for all logs
+ * -----------------------
+ * Keep regular debug/info/driver-state messages on standard logging helpers
+ * (xe_gt_dbg(), xe_gt_info(), xe_gt_warn(), xe_gt_err(), drm_dbg(), drm_info()).
+ * RAS macros are for structured fault reporting only.
+ */
+
+/*
+ * Common backend helper
+ */
+__printf(6, 7)
+void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
+		  u16 sig_id, u32 cper_sev, int errno_val,
+		  const char *fmt, ...);
+
+/*
+ * Driver-facing reporting macros
+ */
+
+/* FATAL */
+#define xe_ras_log_probe(xe, errno, fmt, ...) \
+	__xe_ras_log((xe), NULL, XE_SIG_PROBE, CPER_SEV_FATAL, \
+		     (errno), fmt, ##__VA_ARGS__)
+
+#define xe_ras_log_wedged(xe, errno, fmt, ...) \
+	__xe_ras_log((xe), NULL, XE_SIG_WEDGED, CPER_SEV_FATAL, \
+		     (errno), fmt, ##__VA_ARGS__)
+
+#define xe_ras_log_survivability(xe, errno, fmt, ...) \
+	__xe_ras_log((xe), NULL, XE_SIG_SURVIVABILITY, CPER_SEV_FATAL, \
+		     (errno), fmt, ##__VA_ARGS__)
+
+/* RECOVERABLE */
+#define xe_ras_log_fw(xe, gt, errno, fmt, ...) \
+	__xe_ras_log((xe), (gt), XE_SIG_FW, CPER_SEV_RECOVERABLE, \
+		     (errno), fmt, ##__VA_ARGS__)
+
+#define xe_ras_log_gt_tdr(xe, gt, errno, fmt, ...) \
+	__xe_ras_log((xe), (gt), XE_SIG_GT_TDR, CPER_SEV_RECOVERABLE, \
+		     (errno), fmt, ##__VA_ARGS__)
+
+#define xe_ras_log_mem_fault(xe, gt, errno, fmt, ...) \
+	__xe_ras_log((xe), (gt), XE_SIG_MEM_FAULT, CPER_SEV_RECOVERABLE, \
+		     (errno), fmt, ##__VA_ARGS__)
+
+#define xe_ras_log_io_bus(xe, errno, fmt, ...) \
+	__xe_ras_log((xe), NULL, XE_SIG_IO_BUS, CPER_SEV_RECOVERABLE, \
+		     (errno), fmt, ##__VA_ARGS__)
+
+#endif /* _XE_RAS_LOG_H_ */
-- 
2.34.1

[RFC PATCH v3 3/3] drm/xe: use XE_RAS_WEDGED macro in xe_device_declare_wedged

[Mallesh Koujalagi]

Replace the open-coded drm_err() call with XE_RAS_WEDGED()
macro so that wedge events are reported through the unified
RAS/SIG logging path with a consistent format, CPER severity,
and errno.

Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
---
v2:
- Rebase.

v3:
- Update message in xe_ras_log_wedged().
---
 drivers/gpu/drm/xe/xe_device.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 089872507bdd..8284578b9156 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -61,6 +61,7 @@
 #include "xe_psmi.h"
 #include "xe_pxp.h"
 #include "xe_query.h"
+#include "xe_ras_log.h"
 #include "xe_shrinker.h"
 #include "xe_soc_remapper.h"
 #include "xe_survivability_mode.h"
@@ -1424,12 +1425,12 @@ void xe_device_declare_wedged(struct xe_device *xe)
 	if (!atomic_xchg(&xe->wedged.flag, 1)) {
 		xe->needs_flr_on_fini = true;
 		xe_pm_runtime_get_noresume(xe);
-		drm_err(&xe->drm,
-			"CRITICAL: Xe has declared device %s as wedged.\n"
-			"IOCTLs and executions are blocked.\n"
-			"For recovery procedure, refer to https://docs.kernel.org/gpu/drm-uapi.html#device-wedging\n"
-			"Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/xe/kernel/issues/new\n",
-			dev_name(xe->drm.dev));
+		xe_ras_log_wedged(xe, -EIO,
+				  "CRITICAL: Xe has declared device %s as wedged.\n"
+				  "IOCTLs and executions are blocked.\n"
+				  "For recovery procedure, refer to https://docs.kernel.org/gpu/drm-uapi.html#device-wedging\n"
+				  "Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/xe/kernel/issues/new\n",
+				  dev_name(xe->drm.dev));
 	}
 
 	for_each_gt(gt, xe, id)
-- 
2.34.1

✗ CI.checkpatch: warning for drm/xe: Structured RAS error logging infrastructure (rev3)

[Patchwork]

== Series Details ==

Series: drm/xe: Structured RAS error logging infrastructure (rev3)
URL   : https://patchwork.freedesktop.org/series/168333/
State : warning

== Summary ==

+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
061140b9bc586ae7f40abc1249c97e1cc72d1b9d
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 6df66520c1d16299c9345600a09b22c984143055
Author: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Date:   Wed Jun 17 16:17:15 2026 +0530

    drm/xe: use XE_RAS_WEDGED macro in xe_device_declare_wedged
    
    Replace the open-coded drm_err() call with XE_RAS_WEDGED()
    macro so that wedge events are reported through the unified
    RAS/SIG logging path with a consistent format, CPER severity,
    and errno.
    
    Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
+ /mt/dim checkpatch 1f1e03ee0c160129c336e9301aeed557f406153b drm-intel
f4f11020d39d drm/xe: Add error Signature IDs for RAS logging
-:13: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#13: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 29 lines checked
c994e6fd52f4 drm/xe: Add RAS logging helpers
-:28: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#28: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 178 lines checked
6df66520c1d1 drm/xe: use XE_RAS_WEDGED macro in xe_device_declare_wedged

✗ CI.KUnit: failure for drm/xe: Structured RAS error logging infrastructure (rev3)

[Patchwork]

== Series Details ==

Series: drm/xe: Structured RAS error logging infrastructure (rev3)
URL   : https://patchwork.freedesktop.org/series/168333/
State : failure

== Summary ==

+ trap cleanup EXIT
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/xe/.kunitconfig
[11:11:18] Configuring KUnit Kernel ...
Generating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[11:11:23] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
ERROR:root:/usr/bin/ld: drivers/gpu/drm/xe/xe_ras_log.o: in function `__xe_ras_log':
xe_ras_log.c:(.text+0xe0): undefined reference to `cper_severity_str'
/usr/bin/ld: xe_ras_log.c:(.text+0x102): undefined reference to `cper_severity_str'
collect2: error: ld returned 1 exit status
make[3]: *** [../scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
make[2]: *** [/kernel/Makefile:1338: vmlinux] Error 2
make[1]: *** [/kernel/Makefile:248: __sub-make] Error 2
make: *** [Makefile:248: __sub-make] Error 2

+ cleanup
++ stat -c %u:%g /kernel
+ chown -R 1003:1003 /kernel

RE: [RFC PATCH v3 3/3] drm/xe: use XE_RAS_WEDGED macro in xe_device_declare_wedged

[Bhadane, Dnyaneshwar]

> -----Original Message-----
> From: Intel-xe <intel-xe-bounces@lists.freedesktop.org> On Behalf Of Mallesh
> Koujalagi
> Sent: Wednesday, June 17, 2026 4:17 PM
> To: intel-xe@lists.freedesktop.org; Vivi, Rodrigo <rodrigo.vivi@intel.com>;
> Brost, Matthew <matthew.brost@intel.com>;
> thomas.hellstrom@linux.intel.com
> Cc: Gupta, Anshuman <anshuman.gupta@intel.com>; Nilawar, Badal
> <badal.nilawar@intel.com>; Belgaumkar, Vinay
> <vinay.belgaumkar@intel.com>; Iddamsetty, Aravind
> <aravind.iddamsetty@intel.com>; Tauro, Riana <riana.tauro@intel.com>;
> Poosa, Karthik <karthik.poosa@intel.com>; Anirban, Sk
> <sk.anirban@intel.com>; Jadav, Raag <raag.jadav@intel.com>; Koujalagi,
> Mallesh <mallesh.koujalagi@intel.com>
> Subject: [RFC PATCH v3 3/3] drm/xe: use XE_RAS_WEDGED macro in
> xe_device_declare_wedged
> 
Hello, 
nitpick. Please update patch subject the /s/XE_RAS_WEDGED /xe_ras_log_wedged in next rev.
> Replace the open-coded drm_err() call with XE_RAS_WEDGED() macro so that
                                                                                  ^/s/XE_RAS_WEDGED /xe_ras_log_wedged


Dnyaneshwar

> wedge events are reported through the unified RAS/SIG logging path with a
> consistent format, CPER severity, and errno.
> 
> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> ---
> v2:
> - Rebase.
> 
> v3:
> - Update message in xe_ras_log_wedged().
> ---
>  drivers/gpu/drm/xe/xe_device.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index 089872507bdd..8284578b9156 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -61,6 +61,7 @@
>  #include "xe_psmi.h"
>  #include "xe_pxp.h"
>  #include "xe_query.h"
> +#include "xe_ras_log.h"
>  #include "xe_shrinker.h"
>  #include "xe_soc_remapper.h"
>  #include "xe_survivability_mode.h"
> @@ -1424,12 +1425,12 @@ void xe_device_declare_wedged(struct
> xe_device *xe)
>  	if (!atomic_xchg(&xe->wedged.flag, 1)) {
>  		xe->needs_flr_on_fini = true;
>  		xe_pm_runtime_get_noresume(xe);
> -		drm_err(&xe->drm,
> -			"CRITICAL: Xe has declared device %s as wedged.\n"
> -			"IOCTLs and executions are blocked.\n"
> -			"For recovery procedure, refer to
> https://docs.kernel.org/gpu/drm-uapi.html#device-wedging\n"
> -			"Please file a _new_ bug report at
> https://gitlab.freedesktop.org/drm/xe/kernel/issues/new\n",
> -			dev_name(xe->drm.dev));
> +		xe_ras_log_wedged(xe, -EIO,
> +				  "CRITICAL: Xe has declared device %s as
> wedged.\n"
> +				  "IOCTLs and executions are blocked.\n"
> +				  "For recovery procedure, refer to
> https://docs.kernel.org/gpu/drm-uapi.html#device-wedging\n"
> +				  "Please file a _new_ bug report at
> https://gitlab.freedesktop.org/drm/xe/kernel/issues/new\n",
> +				  dev_name(xe->drm.dev));
>  	}
> 
>  	for_each_gt(gt, xe, id)
> --
> 2.34.1

Re: [RFC PATCH v3 2/3] drm/xe: Add RAS logging helpers

[Tauro, Riana]

On 17-06-2026 16:17, Mallesh Koujalagi wrote:
> Add xe_ras_log.c and xe_ras_log.h so the driver can report
> faults in a structured, machine-readable way.
>
> The core is __xe_ras_log(), which emits a single log line with:
> SIG_ID, severity, location (device or tile/GT), errno, and message.
> Fatal faults go to drm_err(); recoverable ones to drm_warn().
>
> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> ---
> v3:
> - Refer "Tile%u" and "GT%u" strings. (Michal Wajdeczko)
> - Remov xe_cper_severity_str(). (Michal Wajdeczko/Riana)
> - Move __xe_ras_log() function to xe_ras_log.h. (Michal Wajdeczko)
> - Make macro function properly.
> - Remove *_FIRST and *_LAST macro. (Michal Wajdeczko/Riana)
> - Add sig id documents. (Riana)
> - Change macro function same prefix as the file.
> - Handle __xe_ras_log() function with variable format.
> ---
>   drivers/gpu/drm/xe/Makefile     |   1 +
>   drivers/gpu/drm/xe/xe_ras_log.c |  63 +++++++++++++++++++
>   drivers/gpu/drm/xe/xe_ras_log.h | 108 ++++++++++++++++++++++++++++++++
>   3 files changed, 172 insertions(+)
>   create mode 100644 drivers/gpu/drm/xe/xe_ras_log.c
>   create mode 100644 drivers/gpu/drm/xe/xe_ras_log.h
>
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index 8e7b146880f4..607c9b099d03 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -114,6 +114,7 @@ xe-y += xe_bb.o \
>   	xe_query.o \
>   	xe_range_fence.o \
>   	xe_ras.o \
> +	xe_ras_log.o \
>   	xe_reg_sr.o \
>   	xe_reg_whitelist.o \
>   	xe_ring_ops.o \
> diff --git a/drivers/gpu/drm/xe/xe_ras_log.c b/drivers/gpu/drm/xe/xe_ras_log.c
> new file mode 100644
> index 000000000000..0e836ef5dcf6
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_ras_log.c
> @@ -0,0 +1,63 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#include <drm/drm_print.h>
> +
> +#include "xe_device.h"
> +#include "xe_gt.h"
> +#include "xe_ras_log.h"
> +
> +/**
> + * __xe_ras_log - Emit a structured RAS log entry

Why __?

> + * @xe: xe device instance
> + * @gt: GT instance where the error occurred, or NULL if device-wide
> + * @sig_id: signature ID from xe_sig_ids.h identifying the error class
> + * @cper_sev: CPER severity (one of CPER_SEV_FATAL, CPER_SEV_RECOVERABLE, etc.)

Add enum  name instead

> + * @errno_val: negative errno describing the error condition

Why do we need error no?

> + * @fmt: printf-style format string
> + * @...: format arguments
> + *
> + * Formats the message and emits a kernel log line via drm_err() for fatal
> + * events or drm_warn() for all others. CPER record generation and hex dump
> + * are planned as follow-ups.
> + *
> + * Format:
> + *   [xe-err] SIG_ID = <id> Severity = <sev> Location = <loc> Errno = <n> Message = "<msg>"

You are using both error and warn but here it's only xe-err.
Isn't this misleading?

> + */
> +__printf(6, 7)
> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
> +		  u16 sig_id, u32 cper_sev, int errno_val,
> +		  const char *fmt, ...)
> +{
> +	char loc[32];
> +	struct va_format vaf;
> +	va_list ap;
> +
> +	if (gt)
> +		snprintf(loc, sizeof(loc), "tile%u/gt%u",
> +			 gt->tile->id, gt->info.id);
> +	else
> +		snprintf(loc, sizeof(loc), "device");
> +
> +	va_start(ap, fmt);
> +	vaf.fmt = fmt;
> +	vaf.va = &ap;
> +
> +	if (cper_sev == CPER_SEV_FATAL)
> +		drm_err(&xe->drm,
> +			"[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
> +			sig_id, cper_severity_str(cper_sev), loc,
> +			errno_val, &vaf);
> +	else
> +		drm_warn(&xe->drm,
> +			 "[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
> +			 sig_id, cper_severity_str(cper_sev), loc,
> +			 errno_val, &vaf);
> +
> +	va_end(ap);
> +
> +	/* TODO: Add CPER record driver handler */
> +	/* TODO: Add RAS dump cper hex handler */
> +}
> diff --git a/drivers/gpu/drm/xe/xe_ras_log.h b/drivers/gpu/drm/xe/xe_ras_log.h
> new file mode 100644
> index 000000000000..08318dea75a9
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_ras_log.h
> @@ -0,0 +1,108 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#ifndef _XE_RAS_LOG_H_
> +#define _XE_RAS_LOG_H_
> +
> +#include <linux/cper.h>
> +
> +#include "xe_sig_ids.h"
> +
> +struct xe_device;
> +struct xe_gt;
> +
> +/**
> + * DOC: RAS structured logging and SIG_IDs

Link this document.  Add a  brief heading

> + *
> + * What this file is for
> + * ---------------------

Once  this document is generated.
"this file" does not indicate what you are referring to.
Use general doc headings

> + * Use the xe_ras_log_*() macros to report faults in a
> + * machine-readable way.
> + *
> + * What is a SIG_ID?
> + * -----------------
> + * A SIG_ID (defined in xe_sig_ids.h) is a stable numeric error class.

Add full form. Define what is SIG ID

> + * It tells tooling what kind of fault happened, independent of message text.
> + *
> + * Driver SIG_ID classes:
> + *   XE_SIG_PROBE         - probe/init failure
> + *   XE_SIG_WEDGED        - device unrecoverable

wedged does not mean device is not recoverable

> + *   XE_SIG_SURVIVABILITY - degraded/safe mode
>

not really safe mode. Please use actual definition

> + *   XE_SIG_FW            - firmware fault (GuC/HuC/GSC/CSC/PCODE)
> + *   XE_SIG_GT_TDR        - engine hang or GT reset (TDR)
> + *   XE_SIG_MEM_FAULT     - VM/page-fault/GTT error
> + *   XE_SIG_IO_BUS        - PCIe/IOMMU/MMIO bus error
> + *
> + * HW SIG_ID classes are hardware-defined categories, reported by firmware via
> + * CPER records (for example XE_SIG_HW_DEVICE_MEMORY). Driver code does not
> + * emit HW SIG_IDs directly.
> + *   XE_SIG_HW_DEVICE_MEMORY  - device memory errors (e.g. ECC)
> + *   XE_SIG_HW_CORE_COMPUTE   - compute/shader core errors
> + *   XE_SIG_HW_PCIE           - PCIe interface errors
> + *   XE_SIG_HW_FABRIC         - on-package fabric errors

on-package?

> + *   XE_SIG_HW_SOC_INTERNAL   - SoC-internal errors
> + *
> + * Why this exists
> + * ---------------
> + * SIG_IDs let RAS tools parse logs reliably, correlate CPER events, and apply
> + * policy/thresholding without depending on fragile string matching.

What do you mean?

> + *
> + * When to use xe_ras_log_*()
> + * --------------------------
> + * Use these macros when the event is:
> + *   1) a real hardware/firmware fault,
> + *   2) relevant to production monitoring, and

How does one decide if it's relevant?

> + *   3) clearly mapped to one SIG_ID class.
> + *
> + * Do not use for all logs
> + * -----------------------
> + * Keep regular debug/info/driver-state messages on standard logging helpers
> + * (xe_gt_dbg(), xe_gt_info(), xe_gt_warn(), xe_gt_err(), drm_dbg(), drm_info()).
> + * RAS macros are for structured fault reporting only.
> + */
> +
> +/*
> + * Common backend helper
> + */
> +__printf(6, 7)
> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
> +		  u16 sig_id, u32 cper_sev, int errno_val,
> +		  const char *fmt, ...);
> +
> +/*
> + * Driver-facing reporting macros
> + */
> +
> +/* FATAL */
> +#define xe_ras_log_probe(xe, errno, fmt, ...) \
> +	__xe_ras_log((xe), NULL, XE_SIG_PROBE, CPER_SEV_FATAL, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#define xe_ras_log_wedged(xe, errno, fmt, ...) \
> +	__xe_ras_log((xe), NULL, XE_SIG_WEDGED, CPER_SEV_FATAL, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#define xe_ras_log_survivability(xe, errno, fmt, ...) \
> +	__xe_ras_log((xe), NULL, XE_SIG_SURVIVABILITY, CPER_SEV_FATAL, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +/* RECOVERABLE */
> +#define xe_ras_log_fw(xe, gt, errno, fmt, ...) \
> +	__xe_ras_log((xe), (gt), XE_SIG_FW, CPER_SEV_RECOVERABLE, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +

Why force a type of severity here?

Thanks
Riana

> +#define xe_ras_log_gt_tdr(xe, gt, errno, fmt, ...) \
> +	__xe_ras_log((xe), (gt), XE_SIG_GT_TDR, CPER_SEV_RECOVERABLE, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#define xe_ras_log_mem_fault(xe, gt, errno, fmt, ...) \
> +	__xe_ras_log((xe), (gt), XE_SIG_MEM_FAULT, CPER_SEV_RECOVERABLE, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#define xe_ras_log_io_bus(xe, errno, fmt, ...) \
> +	__xe_ras_log((xe), NULL, XE_SIG_IO_BUS, CPER_SEV_RECOVERABLE, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#endif /* _XE_RAS_LOG_H_ */

Re: [RFC PATCH v3 1/3] drm/xe: Add error Signature IDs for RAS logging

[Tauro, Riana]

On 17-06-2026 16:17, Mallesh Koujalagi wrote:
> Every GPU fault needs a stable numeric label so monitoring tools can

GPU fault does not need a label. This patch introduces so it's easy for 
tools /script to monitor.

> identify what went wrong without parsing log text. Add xe_sig_ids.h
> which defines those labels, called SIG_IDs.
>
> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> ---
> v3:
> - Add HW SIG IDS details. (Riana)
> ---
>   drivers/gpu/drm/xe/xe_sig_ids.h | 29 +++++++++++++++++++++++++++++
>   1 file changed, 29 insertions(+)
>   create mode 100644 drivers/gpu/drm/xe/xe_sig_ids.h
>
> diff --git a/drivers/gpu/drm/xe/xe_sig_ids.h b/drivers/gpu/drm/xe/xe_sig_ids.h
> new file mode 100644
> index 000000000000..7badd0d7ad72
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_sig_ids.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#ifndef _XE_SIG_IDS_H_
> +#define _XE_SIG_IDS_H_

Document would be more relevant here

> +
> +/*
> + * Driver SIG_IDs
> + */
> +#define XE_SIG_PROBE			1  /* FATAL: probe failed */
> +#define XE_SIG_WEDGED			2  /* FATAL: device wedged */
> +#define XE_SIG_SURVIVABILITY		3  /* FATAL: survivability mode */
> +#define XE_SIG_FW			4  /* RECOVERABLE: GuC/HuC/UC/GSC/CSC/PCODE */
> +#define XE_SIG_GT_TDR			5  /* RECOVERABLE: engine hang / reset */
> +#define XE_SIG_MEM_FAULT		6  /* RECOVERABLE: VM bind, page fault, GTT */
> +#define XE_SIG_IO_BUS			7  /* RECOVERABLE: runtime PCIe/IOMMU/MMIO */
> +
> +/*
> + * HW SIG_IDs

Acronym needed? Mention Hardware error

> + */
> +#define XE_SIG_HW_DEVICE_MEMORY		8  /* Device memory errors (e.g. ECC) */

example not needed. If required please define

> +#define XE_SIG_HW_CORE_COMPUTE		9  /* Compute/shader core errors */
> +#define XE_SIG_HW_PCIE			10 /* PCIe interface errors */
> +#define XE_SIG_HW_FABRIC		11 /* On-package fabric errors */
on-package?

Thanks
Riana


> +#define XE_SIG_HW_SOC_INTERNAL		12 /* SoC-internal errors */
> +
> +#endif /* _XE_SIG_IDS_H_ */

Re: [RFC PATCH v3 1/3] drm/xe: Add error Signature IDs for RAS logging

[Michal Wajdeczko]

On 6/17/2026 12:47 PM, Mallesh Koujalagi wrote:
> Every GPU fault needs a stable numeric label so monitoring tools can

so the goal is to assign unique number to each GPU error that we report?

can't we teach the monitoring tools to use the message pattern instead?

or maybe it's not about unique signature but rather class of Xe GPU errors?
like HW_ERR defined in [1] for generic hardware errors?

[1] https://elixir.bootlin.com/linux/v7.1/source/include/linux/printk.h#L118

> identify what went wrong without parsing log text. 

hmm, but they will have to parse this text already to find that ID

> Add xe_sig_ids.h
> which defines those labels, called SIG_IDs.

SIG_ID looks like an acronym already - can we know the full real name?

the 'signature' suggests uniqueness, but below definitions are more like a 'class' of errors/faults
> 
> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> ---
> v3:
> - Add HW SIG IDS details. (Riana)
> ---
>  drivers/gpu/drm/xe/xe_sig_ids.h | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>  create mode 100644 drivers/gpu/drm/xe/xe_sig_ids.h
> 
> diff --git a/drivers/gpu/drm/xe/xe_sig_ids.h b/drivers/gpu/drm/xe/xe_sig_ids.h
> new file mode 100644
> index 000000000000..7badd0d7ad72
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_sig_ids.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#ifndef _XE_SIG_IDS_H_
> +#define _XE_SIG_IDS_H_
> +
> +/*
> + * Driver SIG_IDs

please add kernel-doc for SIG_IDs itself
maybe then it will be clear what is it

based on the "Every GPU fault needs a stable numeric label"
maybe the more appropriate name would be names like:

	XE_ERROR_
	XE_FAULT_


> + */
> +#define XE_SIG_PROBE			1  /* FATAL: probe failed */
> +#define XE_SIG_WEDGED			2  /* FATAL: device wedged */
> +#define XE_SIG_SURVIVABILITY		3  /* FATAL: survivability mode */
> +#define XE_SIG_FW			4  /* RECOVERABLE: GuC/HuC/UC/GSC/CSC/PCODE */
> +#define XE_SIG_GT_TDR			5  /* RECOVERABLE: engine hang / reset */
> +#define XE_SIG_MEM_FAULT		6  /* RECOVERABLE: VM bind, page fault, GTT */
> +#define XE_SIG_IO_BUS			7  /* RECOVERABLE: runtime PCIe/IOMMU/MMIO */

at this patch, there is no description what FATAL or RECOVERABLE (severity?) really means here
also, if there is a strict relation between SIG and its severity, then maybe those definitions should look like:

#define XE_SIG_PROBE			XE_SIG(1, FATAL)
#define XE_SIG_WEDGED			XE_SIG(2, FATAL)
...

but

> +
> +/*
> + * HW SIG_IDs
> + */

below SIGs do not have associated severity
why the same family of IDs is defined so differently?

> +#define XE_SIG_HW_DEVICE_MEMORY		8  /* Device memory errors (e.g. ECC) */
> +#define XE_SIG_HW_CORE_COMPUTE		9  /* Compute/shader core errors */
> +#define XE_SIG_HW_PCIE			10 /* PCIe interface errors */
> +#define XE_SIG_HW_FABRIC		11 /* On-package fabric errors */
> +#define XE_SIG_HW_SOC_INTERNAL		12 /* SoC-internal errors */

what's the plan for extending SW or HW SIG_IDs in the future?
as now it looks that will not be able to have new SW IDs together with old ones

and I guess the goal is to not change the IDs assignments

> +
> +#endif /* _XE_SIG_IDS_H_ */

Re: [RFC PATCH v3 2/3] drm/xe: Add RAS logging helpers

[Michal Wajdeczko]

On 6/17/2026 12:47 PM, Mallesh Koujalagi wrote:
> Add xe_ras_log.c and xe_ras_log.h so the driver can report
> faults in a structured, machine-readable way.

hmm, but the dmesg logs are mostly for the human admins, no?

> 
> The core is __xe_ras_log(), which emits a single log line with:
> SIG_ID, severity, location (device or tile/GT), errno, and message.

our dmesg logs are already to some extend structured as they contain:

	severity:	<3>
	driver name: 	xe
	device name:	0000:00:02.0
	subsystem name:	[drm]
	error tag:	*ERROR*
	location:	Tile0:
			Tile0: GT0:
	message:	GuC mmio request ...

> Fatal faults go to drm_err(); recoverable ones to drm_warn().

note that we already have xe_err() and xe_warn() wrappers

> 
> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> ---
> v3:
> - Refer "Tile%u" and "GT%u" strings. (Michal Wajdeczko)
> - Remov xe_cper_severity_str(). (Michal Wajdeczko/Riana)
> - Move __xe_ras_log() function to xe_ras_log.h. (Michal Wajdeczko)
> - Make macro function properly.
> - Remove *_FIRST and *_LAST macro. (Michal Wajdeczko/Riana)
> - Add sig id documents. (Riana)
> - Change macro function same prefix as the file.
> - Handle __xe_ras_log() function with variable format.
> ---
>  drivers/gpu/drm/xe/Makefile     |   1 +
>  drivers/gpu/drm/xe/xe_ras_log.c |  63 +++++++++++++++++++
>  drivers/gpu/drm/xe/xe_ras_log.h | 108 ++++++++++++++++++++++++++++++++
>  3 files changed, 172 insertions(+)
>  create mode 100644 drivers/gpu/drm/xe/xe_ras_log.c
>  create mode 100644 drivers/gpu/drm/xe/xe_ras_log.h
> 
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index 8e7b146880f4..607c9b099d03 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -114,6 +114,7 @@ xe-y += xe_bb.o \
>  	xe_query.o \
>  	xe_range_fence.o \
>  	xe_ras.o \
> +	xe_ras_log.o \
>  	xe_reg_sr.o \
>  	xe_reg_whitelist.o \
>  	xe_ring_ops.o \
> diff --git a/drivers/gpu/drm/xe/xe_ras_log.c b/drivers/gpu/drm/xe/xe_ras_log.c
> new file mode 100644
> index 000000000000..0e836ef5dcf6
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_ras_log.c
> @@ -0,0 +1,63 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#include <drm/drm_print.h>
> +
> +#include "xe_device.h"
> +#include "xe_gt.h"
> +#include "xe_ras_log.h"
> +
> +/**
> + * __xe_ras_log - Emit a structured RAS log entry
> + * @xe: xe device instance
> + * @gt: GT instance where the error occurred, or NULL if device-wide
> + * @sig_id: signature ID from xe_sig_ids.h identifying the error class
> + * @cper_sev: CPER severity (one of CPER_SEV_FATAL, CPER_SEV_RECOVERABLE, etc.)
> + * @errno_val: negative errno describing the error condition
> + * @fmt: printf-style format string
> + * @...: format arguments
> + *
> + * Formats the message and emits a kernel log line via drm_err() for fatal
> + * events or drm_warn() for all others. CPER record generation and hex dump
> + * are planned as follow-ups.
> + *
> + * Format:
> + *   [xe-err] SIG_ID = <id> Severity = <sev> Location = <loc> Errno = <n> Message = "<msg>"
> + */
> +__printf(6, 7)
> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
> +		  u16 sig_id, u32 cper_sev, int errno_val,
> +		  const char *fmt, ...)
> +{
> +	char loc[32];
> +	struct va_format vaf;
> +	va_list ap;
> +
> +	if (gt)
> +		snprintf(loc, sizeof(loc), "tile%u/gt%u",
> +			 gt->tile->id, gt->info.id);
> +	else
> +		snprintf(loc, sizeof(loc), "device");
> +
> +	va_start(ap, fmt);
> +	vaf.fmt = fmt;
> +	vaf.va = &ap;
> +
> +	if (cper_sev == CPER_SEV_FATAL)
> +		drm_err(&xe->drm,
> +			"[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
> +			sig_id, cper_severity_str(cper_sev), loc,
> +			errno_val, &vaf);
> +	else
> +		drm_warn(&xe->drm,
> +			 "[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
> +			 sig_id, cper_severity_str(cper_sev), loc,
> +			 errno_val, &vaf);

again, this is not a very friendly message for the human admin

can't we just add severity/id pair to our updated xe_printk macros, like

	xe_err_fatal(xe, id, fmt, ...)
	xe_err_recoverable(xe, id, fmt, ...)

	xe_gt_err_fatal(gt, id, fmt, ...)
	xe_gt_err_recoverable(gt, id, fmt, ...)

and print sev/id pair within single tag:

	0000:02.0 xe [drm] *ERROR* [ID=123456] *FATAL* format ...

> +
> +	va_end(ap);
> +
> +	/* TODO: Add CPER record driver handler */
> +	/* TODO: Add RAS dump cper hex handler */
> +}
> diff --git a/drivers/gpu/drm/xe/xe_ras_log.h b/drivers/gpu/drm/xe/xe_ras_log.h
> new file mode 100644
> index 000000000000..08318dea75a9
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_ras_log.h
> @@ -0,0 +1,108 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#ifndef _XE_RAS_LOG_H_
> +#define _XE_RAS_LOG_H_
> +
> +#include <linux/cper.h>
> +
> +#include "xe_sig_ids.h"
> +
> +struct xe_device;
> +struct xe_gt;
> +
> +/**
> + * DOC: RAS structured logging and SIG_IDs
> + *
> + * What this file is for
> + * ---------------------
> + * Use the xe_ras_log_*() macros to report faults in a
> + * machine-readable way.
> + *
> + * What is a SIG_ID?
> + * -----------------
> + * A SIG_ID (defined in xe_sig_ids.h) is a stable numeric error class.

hmm, so a SIG is now a CLASS ?
in the prev patch it was described as 'GPU fault signature'

and this kernel-doc for SIG_IDs should be in .h file where we define those IDs

> + * It tells tooling what kind of fault happened, independent of message text.
> + *
> + * Driver SIG_ID classes:
> + *   XE_SIG_PROBE         - probe/init failure
> + *   XE_SIG_WEDGED        - device unrecoverable

hmm, in drm_dev_wedged_event() we can specify recovery method
so what unrecoverable means here?

> + *   XE_SIG_SURVIVABILITY - degraded/safe mode
> + *   XE_SIG_FW            - firmware fault (GuC/HuC/GSC/CSC/PCODE)
> + *   XE_SIG_GT_TDR        - engine hang or GT reset (TDR)
> + *   XE_SIG_MEM_FAULT     - VM/page-fault/GTT error
> + *   XE_SIG_IO_BUS        - PCIe/IOMMU/MMIO bus error
> + *
> + * HW SIG_ID classes are hardware-defined categories, reported by firmware via
> + * CPER records (for example XE_SIG_HW_DEVICE_MEMORY). Driver code does not
> + * emit HW SIG_IDs directly.

if HW SIGs are HW defined, are below IDs also defined by the HW
or HW just defines different components, and we define IDs for them?

> + *   XE_SIG_HW_DEVICE_MEMORY  - device memory errors (e.g. ECC)
> + *   XE_SIG_HW_CORE_COMPUTE   - compute/shader core errors
> + *   XE_SIG_HW_PCIE           - PCIe interface errors
> + *   XE_SIG_HW_FABRIC         - on-package fabric errors
> + *   XE_SIG_HW_SOC_INTERNAL   - SoC-internal errors
> + *
> + * Why this exists
> + * ---------------
> + * SIG_IDs let RAS tools parse logs reliably, correlate CPER events, and apply

dmesg is not reliable

> + * policy/thresholding without depending on fragile string matching.

if the whole idea is to group our errors per fault class,
then maybe our macros should be used like:

	xe_err_fatal(xe, CLASS, fmt, ...)
	xe_err_recoverable(xe, CLASS, fmt, ...)

and output should be:

	0000:02.0 xe [drm] *ERROR* [PROBE] *FATAL* format ...
	0000:02.0 xe [drm] *ERROR* [TDR] *RECOVERABLE* format ...

as printing magic ID numbers is not very friendly

and any 'machine structured output' should be exposed elsewhere?
maybe as sysfs file on the xe module level (to catch probe errors)

and maybe start with that alternate method first,
and use dmesg logging only as a best-effort informational step?

> + *
> + * When to use xe_ras_log_*()
> + * --------------------------
> + * Use these macros when the event is:
> + *   1) a real hardware/firmware fault,
> + *   2) relevant to production monitoring, and
> + *   3) clearly mapped to one SIG_ID class.
> + *
> + * Do not use for all logs
> + * -----------------------
> + * Keep regular debug/info/driver-state messages on standard logging helpers
> + * (xe_gt_dbg(), xe_gt_info(), xe_gt_warn(), xe_gt_err(), drm_dbg(), drm_info()).
> + * RAS macros are for structured fault reporting only.
> + */
> +
> +/*
> + * Common backend helper
> + */
> +__printf(6, 7)
> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
> +		  u16 sig_id, u32 cper_sev, int errno_val,
> +		  const char *fmt, ...);
> +
> +/*
> + * Driver-facing reporting macros
> + */
> +
> +/* FATAL */
> +#define xe_ras_log_probe(xe, errno, fmt, ...) \
> +	__xe_ras_log((xe), NULL, XE_SIG_PROBE, CPER_SEV_FATAL, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#define xe_ras_log_wedged(xe, errno, fmt, ...) \
> +	__xe_ras_log((xe), NULL, XE_SIG_WEDGED, CPER_SEV_FATAL, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#define xe_ras_log_survivability(xe, errno, fmt, ...) \
> +	__xe_ras_log((xe), NULL, XE_SIG_SURVIVABILITY, CPER_SEV_FATAL, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +/* RECOVERABLE */
> +#define xe_ras_log_fw(xe, gt, errno, fmt, ...) \
> +	__xe_ras_log((xe), (gt), XE_SIG_FW, CPER_SEV_RECOVERABLE, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#define xe_ras_log_gt_tdr(xe, gt, errno, fmt, ...) \
> +	__xe_ras_log((xe), (gt), XE_SIG_GT_TDR, CPER_SEV_RECOVERABLE, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#define xe_ras_log_mem_fault(xe, gt, errno, fmt, ...) \
> +	__xe_ras_log((xe), (gt), XE_SIG_MEM_FAULT, CPER_SEV_RECOVERABLE, \
> +		     (errno), fmt, ##__VA_ARGS__)
> +
> +#define xe_ras_log_io_bus(xe, errno, fmt, ...) \
> +	__xe_ras_log((xe), NULL, XE_SIG_IO_BUS, CPER_SEV_RECOVERABLE, \
> +		     (errno), fmt, ##__VA_ARGS__)

IMO those RAS customized macros, should be per severity and take
a CLASS as a param since there is much less severity levels than
your new SIG_IDs fault classes, so it scales better

	xe_err_fatal(xe, PROBE, fmt, ...)
	xe_err_recoverable(xe, IO_BUS, fmt, ...)

and I'm not sure that there is 1:1 relation between CLASS and severity

> +
> +#endif /* _XE_RAS_LOG_H_ */

Re: [RFC PATCH v3 3/3] drm/xe: use XE_RAS_WEDGED macro in xe_device_declare_wedged

[Michal Wajdeczko]

On 6/17/2026 12:47 PM, Mallesh Koujalagi wrote:
> Replace the open-coded drm_err() call with XE_RAS_WEDGED()
> macro so that wedge events are reported through the unified
> RAS/SIG logging path with a consistent format, CPER severity,
> and errno.
> 
> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> ---
> v2:
> - Rebase.
> 
> v3:
> - Update message in xe_ras_log_wedged().
> ---
>  drivers/gpu/drm/xe/xe_device.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index 089872507bdd..8284578b9156 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -61,6 +61,7 @@
>  #include "xe_psmi.h"
>  #include "xe_pxp.h"
>  #include "xe_query.h"
> +#include "xe_ras_log.h"
>  #include "xe_shrinker.h"
>  #include "xe_soc_remapper.h"
>  #include "xe_survivability_mode.h"
> @@ -1424,12 +1425,12 @@ void xe_device_declare_wedged(struct xe_device *xe)
>  	if (!atomic_xchg(&xe->wedged.flag, 1)) {
>  		xe->needs_flr_on_fini = true;
>  		xe_pm_runtime_get_noresume(xe);
> -		drm_err(&xe->drm,
> -			"CRITICAL: Xe has declared device %s as wedged.\n"
> -			"IOCTLs and executions are blocked.\n"
> -			"For recovery procedure, refer to https://docs.kernel.org/gpu/drm-uapi.html#device-wedging\n"
> -			"Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/xe/kernel/issues/new\n",
> -			dev_name(xe->drm.dev));
> +		xe_ras_log_wedged(xe, -EIO,

who really cares about the errno if machine will only look at class and severity?

if relevant for deep-dive analysis, it should be printed as part of the regular message

> +				  "CRITICAL: Xe has declared device %s as wedged.\n"

hmm, so now we will have all this in one log line:

	*ERROR*
	[xe-err]
	Severity = FATAL
	CRITICAL:

and full message like:

	<3> [0.028976] xe 0000:03:00.0: [drm] *ERROR* [xe-err] SIG_ID = 2 Severity = FATAL Location = device Errno = -5  Xe driver declared device 0000:03:00.0 as wedged. ...

> +				  "IOCTLs and executions are blocked.\n"
> +				  "For recovery procedure, refer to https://docs.kernel.org/gpu/drm-uapi.html#device-wedging\n"
> +				  "Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/xe/kernel/issues/new\n",
> +				  dev_name(xe->drm.dev));

compare with:

	xe_err_fatal(xe, WEDGED, "Xe driver declared device as wedged. ...")
and
	<3> [0.028976] xe 0000:03:00.0: [drm] *ERROR* [WEDGED] *FATAL* Xe driver declared device as wedged.


>  	}
>  
>  	for_each_gt(gt, xe, id)

Re: [RFC PATCH v3 1/3] drm/xe: Add error Signature IDs for RAS logging

[Mallesh, Koujalagi]

[-- Attachment #1: Type: text/plain, Size: 2806 bytes --]


On 19-06-2026 11:18 am, Tauro, Riana wrote:
>
> On 17-06-2026 16:17, Mallesh Koujalagi wrote:
>> Every GPU fault needs a stable numeric label so monitoring tools can
>
> GPU fault does not need a label. This patch introduces so it's easy 
> for tools /script to monitor.
>
You are right. I will update this in the next revision.

>> identify what went wrong without parsing log text. Add xe_sig_ids.h
>> which defines those labels, called SIG_IDs.
>>
>> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>> ---
>> v3:
>> - Add HW SIG IDS details. (Riana)
>> ---
>>   drivers/gpu/drm/xe/xe_sig_ids.h | 29 +++++++++++++++++++++++++++++
>>   1 file changed, 29 insertions(+)
>>   create mode 100644 drivers/gpu/drm/xe/xe_sig_ids.h
>>
>> diff --git a/drivers/gpu/drm/xe/xe_sig_ids.h 
>> b/drivers/gpu/drm/xe/xe_sig_ids.h
>> new file mode 100644
>> index 000000000000..7badd0d7ad72
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_sig_ids.h
>> @@ -0,0 +1,29 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#ifndef _XE_SIG_IDS_H_
>> +#define _XE_SIG_IDS_H_
>
> Document would be more relevant here
>
Ack, I'll move here.
>> +
>> +/*
>> + * Driver SIG_IDs
>> + */
>> +#define XE_SIG_PROBE            1  /* FATAL: probe failed */
>> +#define XE_SIG_WEDGED            2  /* FATAL: device wedged */
>> +#define XE_SIG_SURVIVABILITY        3  /* FATAL: survivability mode */
>> +#define XE_SIG_FW            4  /* RECOVERABLE: 
>> GuC/HuC/UC/GSC/CSC/PCODE */
>> +#define XE_SIG_GT_TDR            5  /* RECOVERABLE: engine hang / 
>> reset */
>> +#define XE_SIG_MEM_FAULT        6  /* RECOVERABLE: VM bind, page 
>> fault, GTT */
>> +#define XE_SIG_IO_BUS            7  /* RECOVERABLE: runtime 
>> PCIe/IOMMU/MMIO */
>> +
>> +/*
>> + * HW SIG_IDs
>
> Acronym needed? Mention Hardware error
>
Good point. I will update the comment to explicitly mention “Hardware 
errors” in the next revision.

>> + */
>> +#define XE_SIG_HW_DEVICE_MEMORY        8  /* Device memory errors 
>> (e.g. ECC) */
>
> example not needed. If required please define
>
Agreed. I will drop the example and keep the comment concise

>> +#define XE_SIG_HW_CORE_COMPUTE        9 /* Compute/shader core 
>> errors */
>> +#define XE_SIG_HW_PCIE            10 /* PCIe interface errors */
>> +#define XE_SIG_HW_FABRIC        11 /* On-package fabric errors */
> on-package?

It refers to the high speed interconnect between dies/tiles within the 
same GPU.

I'll make the comment clearer in next revision.

Thanks,

-/Mallesh

>
> Thanks
> Riana
>
>
>> +#define XE_SIG_HW_SOC_INTERNAL        12 /* SoC-internal errors */
>> +
>> +#endif /* _XE_SIG_IDS_H_ */

[-- Attachment #2: Type: text/html, Size: 5983 bytes --]

Re: [RFC PATCH v3 2/3] drm/xe: Add RAS logging helpers

[Mallesh, Koujalagi]

On 19-06-2026 11:13 am, Tauro, Riana wrote:
>
> On 17-06-2026 16:17, Mallesh Koujalagi wrote:
>> Add xe_ras_log.c and xe_ras_log.h so the driver can report
>> faults in a structured, machine-readable way.
>>
>> The core is __xe_ras_log(), which emits a single log line with:
>> SIG_ID, severity, location (device or tile/GT), errno, and message.
>> Fatal faults go to drm_err(); recoverable ones to drm_warn().
>>
>> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>> ---
>> v3:
>> - Refer "Tile%u" and "GT%u" strings. (Michal Wajdeczko)
>> - Remov xe_cper_severity_str(). (Michal Wajdeczko/Riana)
>> - Move __xe_ras_log() function to xe_ras_log.h. (Michal Wajdeczko)
>> - Make macro function properly.
>> - Remove *_FIRST and *_LAST macro. (Michal Wajdeczko/Riana)
>> - Add sig id documents. (Riana)
>> - Change macro function same prefix as the file.
>> - Handle __xe_ras_log() function with variable format.
>> ---
>>   drivers/gpu/drm/xe/Makefile     |   1 +
>>   drivers/gpu/drm/xe/xe_ras_log.c |  63 +++++++++++++++++++
>>   drivers/gpu/drm/xe/xe_ras_log.h | 108 ++++++++++++++++++++++++++++++++
>>   3 files changed, 172 insertions(+)
>>   create mode 100644 drivers/gpu/drm/xe/xe_ras_log.c
>>   create mode 100644 drivers/gpu/drm/xe/xe_ras_log.h
>>
>> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
>> index 8e7b146880f4..607c9b099d03 100644
>> --- a/drivers/gpu/drm/xe/Makefile
>> +++ b/drivers/gpu/drm/xe/Makefile
>> @@ -114,6 +114,7 @@ xe-y += xe_bb.o \
>>       xe_query.o \
>>       xe_range_fence.o \
>>       xe_ras.o \
>> +    xe_ras_log.o \
>>       xe_reg_sr.o \
>>       xe_reg_whitelist.o \
>>       xe_ring_ops.o \
>> diff --git a/drivers/gpu/drm/xe/xe_ras_log.c 
>> b/drivers/gpu/drm/xe/xe_ras_log.c
>> new file mode 100644
>> index 000000000000..0e836ef5dcf6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_ras_log.c
>> @@ -0,0 +1,63 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#include <drm/drm_print.h>
>> +
>> +#include "xe_device.h"
>> +#include "xe_gt.h"
>> +#include "xe_ras_log.h"
>> +
>> +/**
>> + * __xe_ras_log - Emit a structured RAS log entry
>
> Why __?
>
The __ prefix follows the kernel convention for the function that are 
not meant

to be called directly. In this case __xe_ras_log() is the backend 
implementation, callers

are expected to use the type-safe macros like xe_ras_log_wedged() etc.

Same pattern used elewhere in the kernel e.g. __dev_err()/dev_err().

>> + * @xe: xe device instance
>> + * @gt: GT instance where the error occurred, or NULL if device-wide
>> + * @sig_id: signature ID from xe_sig_ids.h identifying the error class
>> + * @cper_sev: CPER severity (one of CPER_SEV_FATAL, 
>> CPER_SEV_RECOVERABLE, etc.)
>
> Add enum  name instead

The CPER_SEV_* values are defined as macros in <linux/cper.h>, not as an 
enum,

so there isn't an enum type name to reference here.

>
>> + * @errno_val: negative errno describing the error condition
>
> Why do we need error no? 

The errno provides a stable, machine-readable error code along with the 
log message.

This helps monitoring tools and scripts interpret the issue 
correctly—for example,

-EIO on a wedge event indicates the device is no longer responding to I/O.

>> + * @fmt: printf-style format string
>> + * @...: format arguments
>> + *
>> + * Formats the message and emits a kernel log line via drm_err() for 
>> fatal
>> + * events or drm_warn() for all others. CPER record generation and 
>> hex dump
>> + * are planned as follow-ups.
>> + *
>> + * Format:
>> + *   [xe-err] SIG_ID = <id> Severity = <sev> Location = <loc> Errno 
>> = <n> Message = "<msg>"
>
> You are using both error and warn but here it's only xe-err.
> Isn't this misleading?
>
Good catch, I’ll update this in the next revision to reflect both xe-err 
and xe-warn appropriately.

>> + */
>> +__printf(6, 7)
>> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
>> +          u16 sig_id, u32 cper_sev, int errno_val,
>> +          const char *fmt, ...)
>> +{
>> +    char loc[32];
>> +    struct va_format vaf;
>> +    va_list ap;
>> +
>> +    if (gt)
>> +        snprintf(loc, sizeof(loc), "tile%u/gt%u",
>> +             gt->tile->id, gt->info.id);
>> +    else
>> +        snprintf(loc, sizeof(loc), "device");
>> +
>> +    va_start(ap, fmt);
>> +    vaf.fmt = fmt;
>> +    vaf.va = &ap;
>> +
>> +    if (cper_sev == CPER_SEV_FATAL)
>> +        drm_err(&xe->drm,
>> +            "[xe-err] SIG_ID = %u Severity = %s Location = %s Errno 
>> = %d Message = \"%pV\"",
>> +            sig_id, cper_severity_str(cper_sev), loc,
>> +            errno_val, &vaf);
>> +    else
>> +        drm_warn(&xe->drm,
>> +             "[xe-err] SIG_ID = %u Severity = %s Location = %s Errno 
>> = %d Message = \"%pV\"",
>> +             sig_id, cper_severity_str(cper_sev), loc,
>> +             errno_val, &vaf);
>> +
>> +    va_end(ap);
>> +
>> +    /* TODO: Add CPER record driver handler */
>> +    /* TODO: Add RAS dump cper hex handler */
>> +}
>> diff --git a/drivers/gpu/drm/xe/xe_ras_log.h 
>> b/drivers/gpu/drm/xe/xe_ras_log.h
>> new file mode 100644
>> index 000000000000..08318dea75a9
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_ras_log.h
>> @@ -0,0 +1,108 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#ifndef _XE_RAS_LOG_H_
>> +#define _XE_RAS_LOG_H_
>> +
>> +#include <linux/cper.h>
>> +
>> +#include "xe_sig_ids.h"
>> +
>> +struct xe_device;
>> +struct xe_gt;
>> +
>> +/**
>> + * DOC: RAS structured logging and SIG_IDs
>
> Link this document.  Add a  brief heading
>
I’ll update this with a proper heading and link to the documentation.
>> + *
>> + * What this file is for
>> + * ---------------------
>
> Once  this document is generated.
> "this file" does not indicate what you are referring to.
> Use general doc headings
>
Agreed, I’ll rework the wording to use proper documentation-style headings.
>> + * Use the xe_ras_log_*() macros to report faults in a
>> + * machine-readable way.
>> + *
>> + * What is a SIG_ID?
>> + * -----------------
>> + * A SIG_ID (defined in xe_sig_ids.h) is a stable numeric error class.
>
> Add full form. Define what is SIG ID
>
Good point, I’ll expand and define SIG_ID clearly in the next revision.

>> + * It tells tooling what kind of fault happened, independent of 
>> message text.
>> + *
>> + * Driver SIG_ID classes:
>> + *   XE_SIG_PROBE         - probe/init failure
>> + *   XE_SIG_WEDGED        - device unrecoverable
>
> wedged does not mean device is not recoverable

You’re right, I’ll fix the wording to avoid implying it’s always 
unrecoverable.

>
>> + *   XE_SIG_SURVIVABILITY - degraded/safe mode
>>
>
> not really safe mode. Please use actual definition

Agreed, “safe mode” is not accurate. I’ll update it with a more precise 
description

>
>> + *   XE_SIG_FW            - firmware fault (GuC/HuC/GSC/CSC/PCODE)
>> + *   XE_SIG_GT_TDR        - engine hang or GT reset (TDR)
>> + *   XE_SIG_MEM_FAULT     - VM/page-fault/GTT error
>> + *   XE_SIG_IO_BUS        - PCIe/IOMMU/MMIO bus error
>> + *
>> + * HW SIG_ID classes are hardware-defined categories, reported by 
>> firmware via
>> + * CPER records (for example XE_SIG_HW_DEVICE_MEMORY). Driver code 
>> does not
>> + * emit HW SIG_IDs directly.
>> + *   XE_SIG_HW_DEVICE_MEMORY  - device memory errors (e.g. ECC)
>> + *   XE_SIG_HW_CORE_COMPUTE   - compute/shader core errors
>> + *   XE_SIG_HW_PCIE           - PCIe interface errors
>> + *   XE_SIG_HW_FABRIC         - on-package fabric errors
>
> on-package?
>
It refers to the high speed interconnect between dies/tiles within the 
same GPU.

I'll make the comment clearer in next revision.

>> + *   XE_SIG_HW_SOC_INTERNAL   - SoC-internal errors
>> + *
>> + * Why this exists
>> + * ---------------
>> + * SIG_IDs let RAS tools parse logs reliably, correlate CPER events, 
>> and apply
>> + * policy/thresholding without depending on fragile string matching.
>
> What do you mean?
>
I’ll rewrite this section to make it more concrete and easier to understand.

>> + *
>> + * When to use xe_ras_log_*()
>> + * --------------------------
>> + * Use these macros when the event is:
>> + *   1) a real hardware/firmware fault,
>> + *   2) relevant to production monitoring, and
>
> How does one decide if it's relevant?
>
That’s a fair point. I’ll replace this with clearer, more concrete guidance.

>> + *   3) clearly mapped to one SIG_ID class.
>> + *
>> + * Do not use for all logs
>> + * -----------------------
>> + * Keep regular debug/info/driver-state messages on standard logging 
>> helpers
>> + * (xe_gt_dbg(), xe_gt_info(), xe_gt_warn(), xe_gt_err(), drm_dbg(), 
>> drm_info()).
>> + * RAS macros are for structured fault reporting only.
>> + */
>> +
>> +/*
>> + * Common backend helper
>> + */
>> +__printf(6, 7)
>> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
>> +          u16 sig_id, u32 cper_sev, int errno_val,
>> +          const char *fmt, ...);
>> +
>> +/*
>> + * Driver-facing reporting macros
>> + */
>> +
>> +/* FATAL */
>> +#define xe_ras_log_probe(xe, errno, fmt, ...) \
>> +    __xe_ras_log((xe), NULL, XE_SIG_PROBE, CPER_SEV_FATAL, \
>> +             (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_wedged(xe, errno, fmt, ...) \
>> +    __xe_ras_log((xe), NULL, XE_SIG_WEDGED, CPER_SEV_FATAL, \
>> +             (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_survivability(xe, errno, fmt, ...) \
>> +    __xe_ras_log((xe), NULL, XE_SIG_SURVIVABILITY, CPER_SEV_FATAL, \
>> +             (errno), fmt, ##__VA_ARGS__)
>> +
>> +/* RECOVERABLE */
>> +#define xe_ras_log_fw(xe, gt, errno, fmt, ...) \
>> +    __xe_ras_log((xe), (gt), XE_SIG_FW, CPER_SEV_RECOVERABLE, \
>> +             (errno), fmt, ##__VA_ARGS__)
>> +
>
> Why force a type of severity here?

Good point, I’ll check with the architecture team and update accordingly.

Thanks,

-/Mallesh

>
> Thanks
> Riana
>
>> +#define xe_ras_log_gt_tdr(xe, gt, errno, fmt, ...) \
>> +    __xe_ras_log((xe), (gt), XE_SIG_GT_TDR, CPER_SEV_RECOVERABLE, \
>> +             (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_mem_fault(xe, gt, errno, fmt, ...) \
>> +    __xe_ras_log((xe), (gt), XE_SIG_MEM_FAULT, CPER_SEV_RECOVERABLE, \
>> +             (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_io_bus(xe, errno, fmt, ...) \
>> +    __xe_ras_log((xe), NULL, XE_SIG_IO_BUS, CPER_SEV_RECOVERABLE, \
>> +             (errno), fmt, ##__VA_ARGS__)
>> +
>> +#endif /* _XE_RAS_LOG_H_ */

Re: [RFC PATCH v3 1/3] drm/xe: Add error Signature IDs for RAS logging

[Mallesh, Koujalagi]

On 20-06-2026 10:32 pm, Michal Wajdeczko wrote:
>
> On 6/17/2026 12:47 PM, Mallesh Koujalagi wrote:
>> Every GPU fault needs a stable numeric label so monitoring tools can
> so the goal is to assign unique number to each GPU error that we report?

Thanks for questions, happy to clarify.

Not exactly. SIG_IDs represent types of errors,

not individual events. For example, XE_SIG_WEDGED = 2 just mean a 
"device wedged" error happened.

Multiple log message can share the same SIG_ID because they belongs to 
same category.
>
> can't we teach the monitoring tools to use the message pattern instead?

We can and that is basically what HW_ERR "[Hardware Error]" does today. 
But that approach is

fragile. If the message tech changes (Wording etc) the pattern can 
break. So that is reason a

numeric ID like SIG_ID is more stable and acts like a reliable 
interface, even if the message text changes.

>
> or maybe it's not about unique signature but rather class of Xe GPU errors?
> like HW_ERR defined in [1] for generic hardware errors?
>
> [1] https://elixir.bootlin.com/linux/v7.1/source/include/linux/printk.h#L118

Yes, that is the closest comparison. The difference is that SIG_IDs are 
numeric, specific to Xe

and designed to work with CPER.

>> identify what went wrong without parsing log text.
> hmm, but they will have to parse this text already to find that ID

Fair point, I'll fix the commit message. Tool can identify what went 
wrong by matching the stable SIG_ID field,

without relying on message text.

>> Add xe_sig_ids.h
>> which defines those labels, called SIG_IDs.
> SIG_ID looks like an acronym already - can we know the full real name?
SIG_ID expands to “Signature ID.” which is mentioned in the Spec.
>
> the 'signature' suggests uniqueness, but below definitions are more like a 'class' of errors/faults

It designed function as a stable component/category identifier for a 
class of errors, with the specific cause carried separately

errno, message text etc.

>> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>> ---
>> v3:
>> - Add HW SIG IDS details. (Riana)
>> ---
>>   drivers/gpu/drm/xe/xe_sig_ids.h | 29 +++++++++++++++++++++++++++++
>>   1 file changed, 29 insertions(+)
>>   create mode 100644 drivers/gpu/drm/xe/xe_sig_ids.h
>>
>> diff --git a/drivers/gpu/drm/xe/xe_sig_ids.h b/drivers/gpu/drm/xe/xe_sig_ids.h
>> new file mode 100644
>> index 000000000000..7badd0d7ad72
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_sig_ids.h
>> @@ -0,0 +1,29 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#ifndef _XE_SIG_IDS_H_
>> +#define _XE_SIG_IDS_H_
>> +
>> +/*
>> + * Driver SIG_IDs
> please add kernel-doc for SIG_IDs itself
> maybe then it will be clear what is it
Sure, will add in next revision.
>
> based on the "Every GPU fault needs a stable numeric label"
> maybe the more appropriate name would be names like:
>
> 	XE_ERROR_
> 	XE_FAULT_
>
Agreed, need to check with Arch team.
>> + */
>> +#define XE_SIG_PROBE			1  /* FATAL: probe failed */
>> +#define XE_SIG_WEDGED			2  /* FATAL: device wedged */
>> +#define XE_SIG_SURVIVABILITY		3  /* FATAL: survivability mode */
>> +#define XE_SIG_FW			4  /* RECOVERABLE: GuC/HuC/UC/GSC/CSC/PCODE */
>> +#define XE_SIG_GT_TDR			5  /* RECOVERABLE: engine hang / reset */
>> +#define XE_SIG_MEM_FAULT		6  /* RECOVERABLE: VM bind, page fault, GTT */
>> +#define XE_SIG_IO_BUS			7  /* RECOVERABLE: runtime PCIe/IOMMU/MMIO */
> at this patch, there is no description what FATAL or RECOVERABLE (severity?) really means here
> also, if there is a strict relation between SIG and its severity, then maybe those definitions should look like:
>
> #define XE_SIG_PROBE			XE_SIG(1, FATAL)
> #define XE_SIG_WEDGED			XE_SIG(2, FATAL)
> ...
>
> but

Agreed. For driver SIG_IDs, severity is part of the contract, not just 
an incidental comment.

Sure, I can add the severity details in the header.

>> +
>> +/*
>> + * HW SIG_IDs
>> + */
> below SIGs do not have associated severity
> why the same family of IDs is defined so differently?

This is intentional. Driver SIG_IDs are paired with fixed severities via 
the driver logging macros,

while Hardware SIG_IDs identify only the hardware component. Hardware 
severity is not fixed per SIG_ID,

it is carried by the incoming CPER record and may vary per event.

>> +#define XE_SIG_HW_DEVICE_MEMORY		8  /* Device memory errors (e.g. ECC) */
>> +#define XE_SIG_HW_CORE_COMPUTE		9  /* Compute/shader core errors */
>> +#define XE_SIG_HW_PCIE			10 /* PCIe interface errors */
>> +#define XE_SIG_HW_FABRIC		11 /* On-package fabric errors */
>> +#define XE_SIG_HW_SOC_INTERNAL		12 /* SoC-internal errors */
> what's the plan for extending SW or HW SIG_IDs in the future?

The current scheme assumes driver IDs are a fixed low range and HW IDs 
occupy the next contiguous range,

with range alone distinguishing Driver vs Hardware.

> as now it looks that will not be able to have new SW IDs together with old ones
>
> and I guess the goal is to not change the IDs assignments

Yes, the stated goal is stable IDs.

Thanks,

-/Mallesh

>
>> +
>> +#endif /* _XE_SIG_IDS_H_ */

Re: [RFC PATCH v3 2/3] drm/xe: Add RAS logging helpers

[Mallesh, Koujalagi]

On 21-06-2026 12:59 am, Michal Wajdeczko wrote:
>
> On 6/17/2026 12:47 PM, Mallesh Koujalagi wrote:
>> Add xe_ras_log.c and xe_ras_log.h so the driver can report
>> faults in a structured, machine-readable way.
> hmm, but the dmesg logs are mostly for the human admins, no?

You are right, dmesg is mostly for humans. The machine-readable 
interface appears to be the CPER

payload exposed  through xe_error_cper/tracefs, while dmesg is a human 
friendly rendering of the

same event.

>> The core is __xe_ras_log(), which emits a single log line with:
>> SIG_ID, severity, location (device or tile/GT), errno, and message.
> our dmesg logs are already to some extend structured as they contain:
>
> 	severity:	<3>
> 	driver name: 	xe
> 	device name:	0000:00:02.0
> 	subsystem name:	[drm]
> 	error tag:	*ERROR*
> 	location:	Tile0:
> 			Tile0: GT0:
> 	message:	GuC mmio request ...
This patch add is a more uniform fault-event format plus the 
CPER/tracepoint path for machine consumption.
>> Fatal faults go to drm_err(); recoverable ones to drm_warn().
> note that we already have xe_err() and xe_warn() wrappers
Good catch.
>> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>> ---
>> v3:
>> - Refer "Tile%u" and "GT%u" strings. (Michal Wajdeczko)
>> - Remov xe_cper_severity_str(). (Michal Wajdeczko/Riana)
>> - Move __xe_ras_log() function to xe_ras_log.h. (Michal Wajdeczko)
>> - Make macro function properly.
>> - Remove *_FIRST and *_LAST macro. (Michal Wajdeczko/Riana)
>> - Add sig id documents. (Riana)
>> - Change macro function same prefix as the file.
>> - Handle __xe_ras_log() function with variable format.
>> ---
>>   drivers/gpu/drm/xe/Makefile     |   1 +
>>   drivers/gpu/drm/xe/xe_ras_log.c |  63 +++++++++++++++++++
>>   drivers/gpu/drm/xe/xe_ras_log.h | 108 ++++++++++++++++++++++++++++++++
>>   3 files changed, 172 insertions(+)
>>   create mode 100644 drivers/gpu/drm/xe/xe_ras_log.c
>>   create mode 100644 drivers/gpu/drm/xe/xe_ras_log.h
>>
>> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
>> index 8e7b146880f4..607c9b099d03 100644
>> --- a/drivers/gpu/drm/xe/Makefile
>> +++ b/drivers/gpu/drm/xe/Makefile
>> @@ -114,6 +114,7 @@ xe-y += xe_bb.o \
>>   	xe_query.o \
>>   	xe_range_fence.o \
>>   	xe_ras.o \
>> +	xe_ras_log.o \
>>   	xe_reg_sr.o \
>>   	xe_reg_whitelist.o \
>>   	xe_ring_ops.o \
>> diff --git a/drivers/gpu/drm/xe/xe_ras_log.c b/drivers/gpu/drm/xe/xe_ras_log.c
>> new file mode 100644
>> index 000000000000..0e836ef5dcf6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_ras_log.c
>> @@ -0,0 +1,63 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#include <drm/drm_print.h>
>> +
>> +#include "xe_device.h"
>> +#include "xe_gt.h"
>> +#include "xe_ras_log.h"
>> +
>> +/**
>> + * __xe_ras_log - Emit a structured RAS log entry
>> + * @xe: xe device instance
>> + * @gt: GT instance where the error occurred, or NULL if device-wide
>> + * @sig_id: signature ID from xe_sig_ids.h identifying the error class
>> + * @cper_sev: CPER severity (one of CPER_SEV_FATAL, CPER_SEV_RECOVERABLE, etc.)
>> + * @errno_val: negative errno describing the error condition
>> + * @fmt: printf-style format string
>> + * @...: format arguments
>> + *
>> + * Formats the message and emits a kernel log line via drm_err() for fatal
>> + * events or drm_warn() for all others. CPER record generation and hex dump
>> + * are planned as follow-ups.
>> + *
>> + * Format:
>> + *   [xe-err] SIG_ID = <id> Severity = <sev> Location = <loc> Errno = <n> Message = "<msg>"
>> + */
>> +__printf(6, 7)
>> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
>> +		  u16 sig_id, u32 cper_sev, int errno_val,
>> +		  const char *fmt, ...)
>> +{
>> +	char loc[32];
>> +	struct va_format vaf;
>> +	va_list ap;
>> +
>> +	if (gt)
>> +		snprintf(loc, sizeof(loc), "tile%u/gt%u",
>> +			 gt->tile->id, gt->info.id);
>> +	else
>> +		snprintf(loc, sizeof(loc), "device");
>> +
>> +	va_start(ap, fmt);
>> +	vaf.fmt = fmt;
>> +	vaf.va = &ap;
>> +
>> +	if (cper_sev == CPER_SEV_FATAL)
>> +		drm_err(&xe->drm,
>> +			"[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
>> +			sig_id, cper_severity_str(cper_sev), loc,
>> +			errno_val, &vaf);
>> +	else
>> +		drm_warn(&xe->drm,
>> +			 "[xe-err] SIG_ID = %u Severity = %s Location = %s Errno = %d Message = \"%pV\"",
>> +			 sig_id, cper_severity_str(cper_sev), loc,
>> +			 errno_val, &vaf);
> again, this is not a very friendly message for the human admin
>
> can't we just add severity/id pair to our updated xe_printk macros, like
>
> 	xe_err_fatal(xe, id, fmt, ...)
> 	xe_err_recoverable(xe, id, fmt, ...)
>
> 	xe_gt_err_fatal(gt, id, fmt, ...)
> 	xe_gt_err_recoverable(gt, id, fmt, ...)
>
> and print sev/id pair within single tag:
>
> 	0000:02.0 xe [drm] *ERROR* [ID=123456] *FATAL* format ...
Agreed, however we've per file macro reference.
>> +
>> +	va_end(ap);
>> +
>> +	/* TODO: Add CPER record driver handler */
>> +	/* TODO: Add RAS dump cper hex handler */
>> +}
>> diff --git a/drivers/gpu/drm/xe/xe_ras_log.h b/drivers/gpu/drm/xe/xe_ras_log.h
>> new file mode 100644
>> index 000000000000..08318dea75a9
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_ras_log.h
>> @@ -0,0 +1,108 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#ifndef _XE_RAS_LOG_H_
>> +#define _XE_RAS_LOG_H_
>> +
>> +#include <linux/cper.h>
>> +
>> +#include "xe_sig_ids.h"
>> +
>> +struct xe_device;
>> +struct xe_gt;
>> +
>> +/**
>> + * DOC: RAS structured logging and SIG_IDs
>> + *
>> + * What this file is for
>> + * ---------------------
>> + * Use the xe_ras_log_*() macros to report faults in a
>> + * machine-readable way.
>> + *
>> + * What is a SIG_ID?
>> + * -----------------
>> + * A SIG_ID (defined in xe_sig_ids.h) is a stable numeric error class.
> hmm, so a SIG is now a CLASS ?
> in the prev patch it was described as 'GPU fault signature'
Sure, i'll make it consistence.
> and this kernel-doc for SIG_IDs should be in .h file where we define those IDs
Sure, I'll move to header.
>> + * It tells tooling what kind of fault happened, independent of message text.
>> + *
>> + * Driver SIG_ID classes:
>> + *   XE_SIG_PROBE         - probe/init failure
>> + *   XE_SIG_WEDGED        - device unrecoverable
> hmm, in drm_dev_wedged_event() we can specify recovery method
> so what unrecoverable means here?
Good point, I'll fix the comment.
>> + *   XE_SIG_SURVIVABILITY - degraded/safe mode
>> + *   XE_SIG_FW            - firmware fault (GuC/HuC/GSC/CSC/PCODE)
>> + *   XE_SIG_GT_TDR        - engine hang or GT reset (TDR)
>> + *   XE_SIG_MEM_FAULT     - VM/page-fault/GTT error
>> + *   XE_SIG_IO_BUS        - PCIe/IOMMU/MMIO bus error
>> + *
>> + * HW SIG_ID classes are hardware-defined categories, reported by firmware via
>> + * CPER records (for example XE_SIG_HW_DEVICE_MEMORY). Driver code does not
>> + * emit HW SIG_IDs directly.
> if HW SIGs are HW defined, are below IDs also defined by the HW
> or HW just defines different components, and we define IDs for them?
No, the numeric values are not defined by the HW. HW defines the 
categories; we define the IDs for them.
>> + *   XE_SIG_HW_DEVICE_MEMORY  - device memory errors (e.g. ECC)
>> + *   XE_SIG_HW_CORE_COMPUTE   - compute/shader core errors
>> + *   XE_SIG_HW_PCIE           - PCIe interface errors
>> + *   XE_SIG_HW_FABRIC         - on-package fabric errors
>> + *   XE_SIG_HW_SOC_INTERNAL   - SoC-internal errors
>> + *
>> + * Why this exists
>> + * ---------------
>> + * SIG_IDs let RAS tools parse logs reliably, correlate CPER events, and apply
> dmesg is not reliable

dmesg is explicitly not a stable API, it is emitted “for logging purpose,”

while the machine-consumable path is the CPER record

via the existing xe_error_cper tracepoint.

>> + * policy/thresholding without depending on fragile string matching.
> if the whole idea is to group our errors per fault class,
> then maybe our macros should be used like:
>
> 	xe_err_fatal(xe, CLASS, fmt, ...)
> 	xe_err_recoverable(xe, CLASS, fmt, ...)
>
> and output should be:
>
> 	0000:02.0 xe [drm] *ERROR* [PROBE] *FATAL* format ...
> 	0000:02.0 xe [drm] *ERROR* [TDR] *RECOVERABLE* format ...
>
> as printing magic ID numbers is not very friendly
>
> and any 'machine structured output' should be exposed elsewhere?
> maybe as sysfs file on the xe module level (to catch probe errors)
>
> and maybe start with that alternate method first,
> and use dmesg logging only as a best-effort informational step?

We need component based helper, not based on severity.

>> + *
>> + * When to use xe_ras_log_*()
>> + * --------------------------
>> + * Use these macros when the event is:
>> + *   1) a real hardware/firmware fault,
>> + *   2) relevant to production monitoring, and
>> + *   3) clearly mapped to one SIG_ID class.
>> + *
>> + * Do not use for all logs
>> + * -----------------------
>> + * Keep regular debug/info/driver-state messages on standard logging helpers
>> + * (xe_gt_dbg(), xe_gt_info(), xe_gt_warn(), xe_gt_err(), drm_dbg(), drm_info()).
>> + * RAS macros are for structured fault reporting only.
>> + */
>> +
>> +/*
>> + * Common backend helper
>> + */
>> +__printf(6, 7)
>> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
>> +		  u16 sig_id, u32 cper_sev, int errno_val,
>> +		  const char *fmt, ...);
>> +
>> +/*
>> + * Driver-facing reporting macros
>> + */
>> +
>> +/* FATAL */
>> +#define xe_ras_log_probe(xe, errno, fmt, ...) \
>> +	__xe_ras_log((xe), NULL, XE_SIG_PROBE, CPER_SEV_FATAL, \
>> +		     (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_wedged(xe, errno, fmt, ...) \
>> +	__xe_ras_log((xe), NULL, XE_SIG_WEDGED, CPER_SEV_FATAL, \
>> +		     (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_survivability(xe, errno, fmt, ...) \
>> +	__xe_ras_log((xe), NULL, XE_SIG_SURVIVABILITY, CPER_SEV_FATAL, \
>> +		     (errno), fmt, ##__VA_ARGS__)
>> +
>> +/* RECOVERABLE */
>> +#define xe_ras_log_fw(xe, gt, errno, fmt, ...) \
>> +	__xe_ras_log((xe), (gt), XE_SIG_FW, CPER_SEV_RECOVERABLE, \
>> +		     (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_gt_tdr(xe, gt, errno, fmt, ...) \
>> +	__xe_ras_log((xe), (gt), XE_SIG_GT_TDR, CPER_SEV_RECOVERABLE, \
>> +		     (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_mem_fault(xe, gt, errno, fmt, ...) \
>> +	__xe_ras_log((xe), (gt), XE_SIG_MEM_FAULT, CPER_SEV_RECOVERABLE, \
>> +		     (errno), fmt, ##__VA_ARGS__)
>> +
>> +#define xe_ras_log_io_bus(xe, errno, fmt, ...) \
>> +	__xe_ras_log((xe), NULL, XE_SIG_IO_BUS, CPER_SEV_RECOVERABLE, \
>> +		     (errno), fmt, ##__VA_ARGS__)
> IMO those RAS customized macros, should be per severity and take
> a CLASS as a param since there is much less severity levels than
> your new SIG_IDs fault classes, so it scales better
>
> 	xe_err_fatal(xe, PROBE, fmt, ...)
> 	xe_err_recoverable(xe, IO_BUS, fmt, ...)
>
> and I'm not sure that there is 1:1 relation between CLASS and severity

ditto

Thanks,

-/Mallesh

>> +
>> +#endif /* _XE_RAS_LOG_H_ */

Re: [RFC PATCH v3 3/3] drm/xe: use XE_RAS_WEDGED macro in xe_device_declare_wedged

[Mallesh, Koujalagi]

On 21-06-2026 01:09 am, Michal Wajdeczko wrote:
>
> On 6/17/2026 12:47 PM, Mallesh Koujalagi wrote:
>> Replace the open-coded drm_err() call with XE_RAS_WEDGED()
>> macro so that wedge events are reported through the unified
>> RAS/SIG logging path with a consistent format, CPER severity,
>> and errno.
>>
>> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>> ---
>> v2:
>> - Rebase.
>>
>> v3:
>> - Update message in xe_ras_log_wedged().
>> ---
>>   drivers/gpu/drm/xe/xe_device.c | 13 +++++++------
>>   1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
>> index 089872507bdd..8284578b9156 100644
>> --- a/drivers/gpu/drm/xe/xe_device.c
>> +++ b/drivers/gpu/drm/xe/xe_device.c
>> @@ -61,6 +61,7 @@
>>   #include "xe_psmi.h"
>>   #include "xe_pxp.h"
>>   #include "xe_query.h"
>> +#include "xe_ras_log.h"
>>   #include "xe_shrinker.h"
>>   #include "xe_soc_remapper.h"
>>   #include "xe_survivability_mode.h"
>> @@ -1424,12 +1425,12 @@ void xe_device_declare_wedged(struct xe_device *xe)
>>   	if (!atomic_xchg(&xe->wedged.flag, 1)) {
>>   		xe->needs_flr_on_fini = true;
>>   		xe_pm_runtime_get_noresume(xe);
>> -		drm_err(&xe->drm,
>> -			"CRITICAL: Xe has declared device %s as wedged.\n"
>> -			"IOCTLs and executions are blocked.\n"
>> -			"For recovery procedure, refer to https://docs.kernel.org/gpu/drm-uapi.html#device-wedging\n"
>> -			"Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/xe/kernel/issues/new\n",
>> -			dev_name(xe->drm.dev));
>> +		xe_ras_log_wedged(xe, -EIO,
> who really cares about the errno if machine will only look at class and severity?
We need errno to encode the driver-side failure and same stuff need to 
update in cper/tracefs.
>
> if relevant for deep-dive analysis, it should be printed as part of the regular message
Yes, we need to print details since device is declared as wedged.
>
>> +				  "CRITICAL: Xe has declared device %s as wedged.\n"
> hmm, so now we will have all this in one log line:
>
> 	*ERROR*
> 	[xe-err]
> 	Severity = FATAL
> 	CRITICAL:
>
> and full message like:
>
> 	<3> [0.028976] xe 0000:03:00.0: [drm] *ERROR* [xe-err] SIG_ID = 2 Severity = FATAL Location = device Errno = -5  Xe driver declared device 0000:03:00.0 as wedged. ...
Yes, Arch team is inline with that format.
>
>> +				  "IOCTLs and executions are blocked.\n"
>> +				  "For recovery procedure, refer to https://docs.kernel.org/gpu/drm-uapi.html#device-wedging\n"
>> +				  "Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/xe/kernel/issues/new\n",
>> +				  dev_name(xe->drm.dev));
> compare with:
>
> 	xe_err_fatal(xe, WEDGED, "Xe driver declared device as wedged. ...")
> and
> 	<3> [0.028976] xe 0000:03:00.0: [drm] *ERROR* [WEDGED] *FATAL* Xe driver declared device as wedged.
>
Since macro is based on severity what happen when we have PROBE has 
different severity? so we defined macro based on component.

Thanks,

-/Mallesh

>>   	}
>>   
>>   	for_each_gt(gt, xe, id)

Re: [RFC PATCH v3 2/3] drm/xe: Add RAS logging helpers

[Tauro, Riana]

On 24-06-2026 21:33, Mallesh, Koujalagi wrote:
>
> On 21-06-2026 12:59 am, Michal Wajdeczko wrote:
>>
>> On 6/17/2026 12:47 PM, Mallesh Koujalagi wrote:
>>> Add xe_ras_log.c and xe_ras_log.h so the driver can report
>>> faults in a structured, machine-readable way.
>> hmm, but the dmesg logs are mostly for the human admins, no?
>
> You are right, dmesg is mostly for humans. The machine-readable 
> interface appears to be the CPER
>
> payload exposed  through xe_error_cper/tracefs, while dmesg is a human 
> friendly rendering of the
>
> same event.
>
>>> The core is __xe_ras_log(), which emits a single log line with:
>>> SIG_ID, severity, location (device or tile/GT), errno, and message.
>> our dmesg logs are already to some extend structured as they contain:
>>
>>     severity:    <3>
>>     driver name:     xe
>>     device name:    0000:00:02.0
>>     subsystem name:    [drm]
>>     error tag:    *ERROR*
>>     location:    Tile0:
>>             Tile0: GT0:
>>     message:    GuC mmio request ...
> This patch add is a more uniform fault-event format plus the 
> CPER/tracepoint path for machine consumption.
>>> Fatal faults go to drm_err(); recoverable ones to drm_warn().
>> note that we already have xe_err() and xe_warn() wrappers
> Good catch.
>>> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>>> ---
>>> v3:
>>> - Refer "Tile%u" and "GT%u" strings. (Michal Wajdeczko)
>>> - Remov xe_cper_severity_str(). (Michal Wajdeczko/Riana)
>>> - Move __xe_ras_log() function to xe_ras_log.h. (Michal Wajdeczko)
>>> - Make macro function properly.
>>> - Remove *_FIRST and *_LAST macro. (Michal Wajdeczko/Riana)
>>> - Add sig id documents. (Riana)
>>> - Change macro function same prefix as the file.
>>> - Handle __xe_ras_log() function with variable format.
>>> ---
>>>   drivers/gpu/drm/xe/Makefile     |   1 +
>>>   drivers/gpu/drm/xe/xe_ras_log.c |  63 +++++++++++++++++++
>>>   drivers/gpu/drm/xe/xe_ras_log.h | 108 
>>> ++++++++++++++++++++++++++++++++
>>>   3 files changed, 172 insertions(+)
>>>   create mode 100644 drivers/gpu/drm/xe/xe_ras_log.c
>>>   create mode 100644 drivers/gpu/drm/xe/xe_ras_log.h
>>>
>>> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
>>> index 8e7b146880f4..607c9b099d03 100644
>>> --- a/drivers/gpu/drm/xe/Makefile
>>> +++ b/drivers/gpu/drm/xe/Makefile
>>> @@ -114,6 +114,7 @@ xe-y += xe_bb.o \
>>>       xe_query.o \
>>>       xe_range_fence.o \
>>>       xe_ras.o \
>>> +    xe_ras_log.o \
>>>       xe_reg_sr.o \
>>>       xe_reg_whitelist.o \
>>>       xe_ring_ops.o \
>>> diff --git a/drivers/gpu/drm/xe/xe_ras_log.c 
>>> b/drivers/gpu/drm/xe/xe_ras_log.c
>>> new file mode 100644
>>> index 000000000000..0e836ef5dcf6
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/xe/xe_ras_log.c
>>> @@ -0,0 +1,63 @@
>>> +// SPDX-License-Identifier: MIT
>>> +/*
>>> + * Copyright © 2026 Intel Corporation
>>> + */
>>> +
>>> +#include <drm/drm_print.h>
>>> +
>>> +#include "xe_device.h"
>>> +#include "xe_gt.h"
>>> +#include "xe_ras_log.h"
>>> +
>>> +/**
>>> + * __xe_ras_log - Emit a structured RAS log entry
>>> + * @xe: xe device instance
>>> + * @gt: GT instance where the error occurred, or NULL if device-wide
>>> + * @sig_id: signature ID from xe_sig_ids.h identifying the error class
>>> + * @cper_sev: CPER severity (one of CPER_SEV_FATAL, 
>>> CPER_SEV_RECOVERABLE, etc.)
>>> + * @errno_val: negative errno describing the error condition
>>> + * @fmt: printf-style format string
>>> + * @...: format arguments
>>> + *
>>> + * Formats the message and emits a kernel log line via drm_err() 
>>> for fatal
>>> + * events or drm_warn() for all others. CPER record generation and 
>>> hex dump
>>> + * are planned as follow-ups.
>>> + *
>>> + * Format:
>>> + *   [xe-err] SIG_ID = <id> Severity = <sev> Location = <loc> Errno 
>>> = <n> Message = "<msg>"
>>> + */
>>> +__printf(6, 7)
>>> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
>>> +          u16 sig_id, u32 cper_sev, int errno_val,
>>> +          const char *fmt, ...)
>>> +{
>>> +    char loc[32];
>>> +    struct va_format vaf;
>>> +    va_list ap;
>>> +
>>> +    if (gt)
>>> +        snprintf(loc, sizeof(loc), "tile%u/gt%u",
>>> +             gt->tile->id, gt->info.id);
>>> +    else
>>> +        snprintf(loc, sizeof(loc), "device");
>>> +
>>> +    va_start(ap, fmt);
>>> +    vaf.fmt = fmt;
>>> +    vaf.va = &ap;
>>> +
>>> +    if (cper_sev == CPER_SEV_FATAL)
>>> +        drm_err(&xe->drm,
>>> +            "[xe-err] SIG_ID = %u Severity = %s Location = %s Errno 
>>> = %d Message = \"%pV\"",
>>> +            sig_id, cper_severity_str(cper_sev), loc,
>>> +            errno_val, &vaf);
>>> +    else
>>> +        drm_warn(&xe->drm,
>>> +             "[xe-err] SIG_ID = %u Severity = %s Location = %s 
>>> Errno = %d Message = \"%pV\"",
>>> +             sig_id, cper_severity_str(cper_sev), loc,
>>> +             errno_val, &vaf);
>> again, this is not a very friendly message for the human admin
>>
>> can't we just add severity/id pair to our updated xe_printk macros, like
>>
>>     xe_err_fatal(xe, id, fmt, ...)
>>     xe_err_recoverable(xe, id, fmt, ...)
>>
>>     xe_gt_err_fatal(gt, id, fmt, ...)
>>     xe_gt_err_recoverable(gt, id, fmt, ...)
>>
>> and print sev/id pair within single tag:
>>
>>     0000:02.0 xe [drm] *ERROR* [ID=123456] *FATAL* format ...
> Agreed, however we've per file macro reference.
>>> +
>>> +    va_end(ap);
>>> +
>>> +    /* TODO: Add CPER record driver handler */
>>> +    /* TODO: Add RAS dump cper hex handler */
>>> +}
>>> diff --git a/drivers/gpu/drm/xe/xe_ras_log.h 
>>> b/drivers/gpu/drm/xe/xe_ras_log.h
>>> new file mode 100644
>>> index 000000000000..08318dea75a9
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/xe/xe_ras_log.h
>>> @@ -0,0 +1,108 @@
>>> +/* SPDX-License-Identifier: MIT */
>>> +/*
>>> + * Copyright © 2026 Intel Corporation
>>> + */
>>> +
>>> +#ifndef _XE_RAS_LOG_H_
>>> +#define _XE_RAS_LOG_H_
>>> +
>>> +#include <linux/cper.h>
>>> +
>>> +#include "xe_sig_ids.h"
>>> +
>>> +struct xe_device;
>>> +struct xe_gt;
>>> +
>>> +/**
>>> + * DOC: RAS structured logging and SIG_IDs
>>> + *
>>> + * What this file is for
>>> + * ---------------------
>>> + * Use the xe_ras_log_*() macros to report faults in a
>>> + * machine-readable way.
>>> + *
>>> + * What is a SIG_ID?
>>> + * -----------------
>>> + * A SIG_ID (defined in xe_sig_ids.h) is a stable numeric error class.
>> hmm, so a SIG is now a CLASS ?
>> in the prev patch it was described as 'GPU fault signature'
> Sure, i'll make it consistence.
>> and this kernel-doc for SIG_IDs should be in .h file where we define 
>> those IDs
> Sure, I'll move to header.
>>> + * It tells tooling what kind of fault happened, independent of 
>>> message text.
>>> + *
>>> + * Driver SIG_ID classes:
>>> + *   XE_SIG_PROBE         - probe/init failure
>>> + *   XE_SIG_WEDGED        - device unrecoverable
>> hmm, in drm_dev_wedged_event() we can specify recovery method
>> so what unrecoverable means here?
> Good point, I'll fix the comment.
>>> + *   XE_SIG_SURVIVABILITY - degraded/safe mode
>>> + *   XE_SIG_FW            - firmware fault (GuC/HuC/GSC/CSC/PCODE)
>>> + *   XE_SIG_GT_TDR        - engine hang or GT reset (TDR)
>>> + *   XE_SIG_MEM_FAULT     - VM/page-fault/GTT error
>>> + *   XE_SIG_IO_BUS        - PCIe/IOMMU/MMIO bus error
>>> + *
>>> + * HW SIG_ID classes are hardware-defined categories, reported by 
>>> firmware via
>>> + * CPER records (for example XE_SIG_HW_DEVICE_MEMORY). Driver code 
>>> does not
>>> + * emit HW SIG_IDs directly.
>> if HW SIGs are HW defined, are below IDs also defined by the HW
>> or HW just defines different components, and we define IDs for them?
> No, the numeric values are not defined by the HW. HW defines the 
> categories; we define the IDs for them.
>>> + *   XE_SIG_HW_DEVICE_MEMORY  - device memory errors (e.g. ECC)
>>> + *   XE_SIG_HW_CORE_COMPUTE   - compute/shader core errors
>>> + *   XE_SIG_HW_PCIE           - PCIe interface errors
>>> + *   XE_SIG_HW_FABRIC         - on-package fabric errors
>>> + *   XE_SIG_HW_SOC_INTERNAL   - SoC-internal errors
>>> + *
>>> + * Why this exists
>>> + * ---------------
>>> + * SIG_IDs let RAS tools parse logs reliably, correlate CPER 
>>> events, and apply
>> dmesg is not reliable
>
> dmesg is explicitly not a stable API, it is emitted “for logging 
> purpose,”
>
> while the machine-consumable path is the CPER record
>
> via the existing xe_error_cper tracepoint.
>
>>> + * policy/thresholding without depending on fragile string matching.
>> if the whole idea is to group our errors per fault class,
>> then maybe our macros should be used like:
>>
>>     xe_err_fatal(xe, CLASS, fmt, ...)
>>     xe_err_recoverable(xe, CLASS, fmt, ...)
>>
>> and output should be:
>>
>>     0000:02.0 xe [drm] *ERROR* [PROBE] *FATAL* format ...
>>     0000:02.0 xe [drm] *ERROR* [TDR] *RECOVERABLE* format ...
>>
>> as printing magic ID numbers is not very friendly
>>
>> and any 'machine structured output' should be exposed elsewhere?
>> maybe as sysfs file on the xe module level (to catch probe errors)
>>
>> and maybe start with that alternate method first,
>> and use dmesg logging only as a best-effort informational step?
>
> We need component based helper, not based on severity.
>
>>> + *
>>> + * When to use xe_ras_log_*()
>>> + * --------------------------
>>> + * Use these macros when the event is:
>>> + *   1) a real hardware/firmware fault,
>>> + *   2) relevant to production monitoring, and
>>> + *   3) clearly mapped to one SIG_ID class.
>>> + *
>>> + * Do not use for all logs
>>> + * -----------------------
>>> + * Keep regular debug/info/driver-state messages on standard 
>>> logging helpers
>>> + * (xe_gt_dbg(), xe_gt_info(), xe_gt_warn(), xe_gt_err(), 
>>> drm_dbg(), drm_info()).
>>> + * RAS macros are for structured fault reporting only.
>>> + */
>>> +
>>> +/*
>>> + * Common backend helper
>>> + */
>>> +__printf(6, 7)
>>> +void __xe_ras_log(struct xe_device *xe, struct xe_gt *gt,
>>> +          u16 sig_id, u32 cper_sev, int errno_val,
>>> +          const char *fmt, ...);
>>> +
>>> +/*
>>> + * Driver-facing reporting macros
>>> + */
>>> +
>>> +/* FATAL */
>>> +#define xe_ras_log_probe(xe, errno, fmt, ...) \
>>> +    __xe_ras_log((xe), NULL, XE_SIG_PROBE, CPER_SEV_FATAL, \
>>> +             (errno), fmt, ##__VA_ARGS__)
>>> +
>>> +#define xe_ras_log_wedged(xe, errno, fmt, ...) \
>>> +    __xe_ras_log((xe), NULL, XE_SIG_WEDGED, CPER_SEV_FATAL, \
>>> +             (errno), fmt, ##__VA_ARGS__)
>>> +
>>> +#define xe_ras_log_survivability(xe, errno, fmt, ...) \
>>> +    __xe_ras_log((xe), NULL, XE_SIG_SURVIVABILITY, CPER_SEV_FATAL, \
>>> +             (errno), fmt, ##__VA_ARGS__)
>>> +
>>> +/* RECOVERABLE */
>>> +#define xe_ras_log_fw(xe, gt, errno, fmt, ...) \
>>> +    __xe_ras_log((xe), (gt), XE_SIG_FW, CPER_SEV_RECOVERABLE, \
>>> +             (errno), fmt, ##__VA_ARGS__)
>>> +
>>> +#define xe_ras_log_gt_tdr(xe, gt, errno, fmt, ...) \
>>> +    __xe_ras_log((xe), (gt), XE_SIG_GT_TDR, CPER_SEV_RECOVERABLE, \
>>> +             (errno), fmt, ##__VA_ARGS__)
>>> +
>>> +#define xe_ras_log_mem_fault(xe, gt, errno, fmt, ...) \
>>> +    __xe_ras_log((xe), (gt), XE_SIG_MEM_FAULT, CPER_SEV_RECOVERABLE, \
>>> +             (errno), fmt, ##__VA_ARGS__)
>>> +
>>> +#define xe_ras_log_io_bus(xe, errno, fmt, ...) \
>>> +    __xe_ras_log((xe), NULL, XE_SIG_IO_BUS, CPER_SEV_RECOVERABLE, \
>>> +             (errno), fmt, ##__VA_ARGS__)
>> IMO those RAS customized macros, should be per severity and take
>> a CLASS as a param since there is much less severity levels than
>> your new SIG_IDs fault classes, so it scales better
>>
>>     xe_err_fatal(xe, PROBE, fmt, ...)
>>     xe_err_recoverable(xe, IO_BUS, fmt, ...)
>>
>> and I'm not sure that there is 1:1 relation between CLASS and severity
>

Agree with Michal here. Let's not force severity per class.

Developers should be allowed to set severity irrespective of sig id.
Having severity based helpers would also be useful for HW error logs.

Thanks
Riana

> ditto
>
> Thanks,
>
> -/Mallesh
>
>>> +
>>> +#endif /* _XE_RAS_LOG_H_ */