From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
<intel-xe@lists.freedesktop.org>
Cc: <anshuman.gupta@intel.com>, <rodrigo.vivi@intel.com>,
<daniele.ceraolospurio@intel.com>, <raag.jadav@intel.com>,
<riana.tauro@intel.com>, <mallesh.koujalagi@intel.com>,
<aravind.iddamsetty@intel.com>, <himal.prasad.ghimiray@intel.com>,
<arvind.yadav@intel.com>, <syed.abdul.muqthyar.ahmed@intel.com>,
<nitin.r.gote@intel.com>
Subject: Re: [PATCH v3 01/12] drm/xe/cper: Hardware error CPER reporting from xe_log
Date: Thu, 10 Sep 2026 17:09:37 +0530 [thread overview]
Message-ID: <1fab7d15-a447-403c-bc4f-6b33b8dad2de@intel.com> (raw)
In-Reply-To: <c18194ec-cefb-44f6-9338-7470bb7a8ed2@intel.com>
[-- Attachment #1: Type: text/plain, Size: 6816 bytes --]
On 07-09-2026 18:08, Michal Wajdeczko wrote:
>
> On 9/6/2026 7:26 PM, Badal Nilawar wrote:
>> Introduce xe_emit_hardware_error_cper() as public entry point
>> for CPER reporting.
>>
>> Wire xe_log to route hardware SIGIDs through the new helper.
>> No functional change is intended yet, as the CPER emission logic
>> is added in follow-up patches.
>>
>> Signed-off-by: Badal Nilawar<badal.nilawar@intel.com>
>> ---
>> drivers/gpu/drm/xe/Makefile | 2 ++
>> drivers/gpu/drm/xe/xe_cper.c | 37 ++++++++++++++++++++++++++++++++++++
>> drivers/gpu/drm/xe/xe_cper.h | 25 ++++++++++++++++++++++++
>> drivers/gpu/drm/xe/xe_log.c | 17 +++++++++++------
>> 4 files changed, 75 insertions(+), 6 deletions(-)
>> create mode 100644 drivers/gpu/drm/xe/xe_cper.c
>> create mode 100644 drivers/gpu/drm/xe/xe_cper.h
>>
>> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
>> index 67b8b5477639..06b064add77d 100644
>> --- a/drivers/gpu/drm/xe/Makefile
>> +++ b/drivers/gpu/drm/xe/Makefile
>> @@ -166,6 +166,8 @@ xe-$(CONFIG_HWMON) += xe_hwmon.o
>> xe-$(CONFIG_PERF_EVENTS) += xe_pmu.o
>> xe-$(CONFIG_CONFIGFS_FS) += xe_configfs.o
>>
>> +xe-$(CONFIG_UEFI_CPER_X86) += xe_cper.o
> shouldn't we use just CONFIG_UEFI_CPER ?
Will check.
>
>> +
>> # graphics virtualization (SR-IOV) support
>> xe-y += \
>> xe_gt_sriov_vf.o \
>> diff --git a/drivers/gpu/drm/xe/xe_cper.c b/drivers/gpu/drm/xe/xe_cper.c
>> new file mode 100644
>> index 000000000000..e8017e3ee3a0
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_cper.c
>> @@ -0,0 +1,37 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#include <linux/pci.h>
>> +
>> +#include <drm/drm_print.h>
> do we need this?
will add in the patch where it is needed.
>
>> +
>> +#include "xe_cper.h"
>> +#include "xe_device.h"
>> +#include "xe_ras_types.h"
>> +
>> +/**
>> + * xe_emit_hardware_error_cper() - Emit a hardware error CPER record
>> + * @pdev: PCI device associated with the Xe device
>> + * @cper_sev: CPER severity
>> + * @sigid: Error signature identifier
>> + * @error_class: Hardware error classification details
>> + * @response: Response of get counter
>> + *
>> + * Emit a CPER record for a hardware error
>> + */
>> +void xe_emit_hardware_error_cper(struct pci_dev *pdev, int cper_sev, enum xe_sigid sigid,
>> + struct xe_ras_error_class *counter,
>> + struct xe_ras_get_counter_response *response)
>> +{
>> + struct xe_device *xe = pdev_to_xe_device(pdev);
>> +
>> + if (!xe)
>> + return;
>> +
>> + if ((int)sigid >= INTEL_SIGID_GPU_XE_HARDWARE_START)
>> + return;
>> +
>> + /* TODO */
>> +}
>> diff --git a/drivers/gpu/drm/xe/xe_cper.h b/drivers/gpu/drm/xe/xe_cper.h
>> new file mode 100644
>> index 000000000000..c4be7f25a369
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_cper.h
>> @@ -0,0 +1,25 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright © 2026 Intel Corporation
>> + */
>> +
>> +#ifndef _XE_CPER_H_
>> +#define _XE_CPER_H_
>> +
>> +#include "abi/xe_sigid_abi.h"
> maybe just:
>
> enum xe_sigid sigid;
Ok.
>
>> +
>> +struct pci_dev;
>> +struct xe_ras_error_class;
>> +struct xe_ras_get_counter_response;
>> +
>> +#if IS_REACHABLE(CONFIG_UEFI_CPER_X86)
>> +void xe_emit_hardware_error_cper(struct pci_dev *pdev, int cper_sev, enum xe_sigid sigid,
>> + struct xe_ras_error_class *counter,
>> + struct xe_ras_get_counter_response *response);
> since you're introducing xe_cper component, all its public functions
> shall use xe_cper prefix:
>
> xe_cper_emit_hardware_error(
Sure. Kept _cper in the end to indicate cper record of hardware error
is being emitted.
>
> and since all HW errors are expected to come from the xe, no need for pdev:
>
> xe_cper_emit_hardware_error(struct xe_device *xe,
Ok.
>
> also it's better to let the caller pass whatever data was given in xe_log macros:
>
> xe_cper_emit_hardware_error(struct xe_device *xe,
> int cper_sev, enum xe_sigid sigid,
> const void *data, size_t len)
>
> and do any data validation/conversion inside xe_cper code
>
> and since xe_ras_get_counter_response is now optional, just define another function (when needed) that takes already validated data:
>
> xe_cper_emit_hardware_error_details(struct xe_device *xe,
> int cper_sev, enum xe_sigid sigid,
> const struct xe_ras_error_class *counter,
> const struct xe_ras_get_counter_response *response);
Will think about this. Don't want to keep to many layers. May be a one
more wrapper function in xe_cper.c, which will do validation and decide
which path hw or fw cper to follow.
IMO inside log_emit_cper itself validation should be done.
>
>> +#else
>> +static inline void xe_emit_hardware_error_cper(struct pci_dev *pdev, int cper_sev,
>> + enum xe_sigid sigid,
>> + struct xe_ras_error_class *counter,
>> + struct xe_ras_get_counter_response *response) {}
>> +#endif
>> +#endif /* _XE_CPER_H_ */
>> diff --git a/drivers/gpu/drm/xe/xe_log.c b/drivers/gpu/drm/xe/xe_log.c
>> index 5549ef6966fd..2957adec41aa 100644
>> --- a/drivers/gpu/drm/xe/xe_log.c
>> +++ b/drivers/gpu/drm/xe/xe_log.c
>> @@ -8,17 +8,27 @@
>>
>> #include "abi/xe_log_abi.h"
>>
>> +#include "xe_cper.h"
>> #include "xe_device.h"
>> #include "xe_log.h"
>> #include "xe_printk.h"
>>
>> +static bool is_hw_sigid(enum xe_sigid sigid)
>> +{
>> + return (int)sigid >= INTEL_SIGID_GPU_XE_HARDWARE_START;
>> +}
>> +
>> static void log_emit_cper(struct pci_dev *pdev, int cper_sev, enum xe_sigid sigid,
>> u32 component, u32 location, const void *data, size_t len,
>> struct va_format *vaf)
>> {
>> KUNIT_STATIC_STUB_REDIRECT(log_emit_cper, pdev, cper_sev, sigid,
>> component, location, data, len, vaf);
>> - /* TODO */
>> +
>> + if (is_hw_sigid(sigid) && !IS_ERR(data))
>> + xe_emit_hardware_error_cper(pdev, cper_sev, sigid,
>> + (struct xe_ras_error_class *)data, NULL);
> you shouldn't blindly convert data to xe_ras_error_class
> you shall at least check if len == sizeof(xe_ras_error_class)
> and IMO it would be better to move that checks to xe_cper code
> (as maybe we can still emit some CPER records for ERR_PTR data?
Without valid error class no point in emitting hardware CPER. May be as
software CPER this can be considered later.
Thanks,
Badal
>
>
>> + /* TODO software CPER */
>> }
>>
>> static const char *log_unknown_component_prefix(u32 component)
>> @@ -100,11 +110,6 @@ static const char *log_location_prefix(struct pci_dev *pdev, u32 location, char
>> return buf;
>> }
>>
>> -static bool is_hw_sigid(enum xe_sigid sigid)
>> -{
>> - return (int)sigid >= INTEL_SIGID_GPU_XE_HARDWARE_START;
>> -}
>> -
>> static bool is_sev_error(int cper_sev)
>> {
>> return cper_sev != CPER_SEV_INFORMATIONAL;
[-- Attachment #2: Type: text/html, Size: 9137 bytes --]
next prev parent reply other threads:[~2026-09-10 11:46 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 17:26 [PATCH v3 00/12] Add CPER logging support for CRI Badal Nilawar
2026-09-06 17:16 ` ✗ CI.checkpatch: warning for Add CPER logging support for CRI (rev3) Patchwork
2026-09-06 17:18 ` ✓ CI.KUnit: success " Patchwork
2026-09-06 17:26 ` [PATCH v3 01/12] drm/xe/cper: Hardware error CPER reporting from xe_log Badal Nilawar
2026-09-06 17:21 ` sashiko-bot
2026-09-07 12:38 ` Michal Wajdeczko
2026-09-10 11:39 ` Nilawar, Badal [this message]
2026-09-08 10:12 ` Raag Jadav
2026-09-10 12:33 ` Nilawar, Badal
2026-09-06 17:26 ` [PATCH v3 02/12] drm/xe/cper: Retrieve the error counter record for CPER reporting Badal Nilawar
2026-09-06 17:23 ` sashiko-bot
2026-09-08 10:16 ` Raag Jadav
2026-09-09 6:12 ` Raag Jadav
2026-09-10 12:59 ` Nilawar, Badal
2026-09-10 13:19 ` Raag Jadav
2026-09-06 17:26 ` [PATCH v3 03/12] drm/xe/cper: Add Intel specific CPER structures Badal Nilawar
2026-09-07 13:13 ` Michal Wajdeczko
2026-09-10 11:57 ` Nilawar, Badal
2026-09-08 10:18 ` Raag Jadav
2026-09-10 13:36 ` Nilawar, Badal
2026-09-06 17:26 ` [PATCH v3 04/12] drm/xe/cper: Prepare CPER record Badal Nilawar
2026-09-06 17:27 ` sashiko-bot
2026-09-08 10:20 ` Raag Jadav
2026-09-06 17:26 ` [PATCH v3 05/12] drm/xe/xe_ras: Add support to retrieve info queue data for CRI Badal Nilawar
2026-09-06 17:17 ` sashiko-bot
2026-09-09 8:03 ` Raag Jadav
2026-09-06 17:26 ` [PATCH v3 06/12] drm/xe/cper: Prepare Intel CPER error info records Badal Nilawar
2026-09-06 17:30 ` sashiko-bot
2026-09-09 11:58 ` Raag Jadav
2026-09-06 17:26 ` [PATCH v3 07/12] drm/xe/cper: Log CPER records for aggregate counter retrival Badal Nilawar
2026-09-06 17:23 ` sashiko-bot
2026-09-10 6:27 ` Raag Jadav
2026-09-10 22:29 ` Rodrigo Vivi
2026-09-06 17:26 ` [PATCH v3 08/12] drm/xe/xe_ras: Report device memory errors using SIGID Badal Nilawar
2026-09-06 17:27 ` sashiko-bot
2026-09-06 17:26 ` [PATCH v3 09/12] drm/xe/xe_ras: Report core compute " Badal Nilawar
2026-09-06 17:21 ` sashiko-bot
2026-09-06 17:26 ` [PATCH v3 10/12] drm/xe/xe_ras: Report soc internal " Badal Nilawar
2026-09-06 17:26 ` [PATCH v3 11/12] drm/xe/xe_ras: Report correctable " Badal Nilawar
2026-09-06 17:27 ` sashiko-bot
2026-09-06 17:26 ` [PATCH v3 12/12] drm/xe/cper: Emit cper record to trace buf Badal Nilawar
2026-09-06 17:28 ` sashiko-bot
2026-09-10 7:58 ` Raag Jadav
2026-09-06 17:55 ` ✓ Xe.CI.BAT: success for Add CPER logging support for CRI (rev3) Patchwork
2026-09-06 19:02 ` ✗ 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=1fab7d15-a447-403c-bc4f-6b33b8dad2de@intel.com \
--to=badal.nilawar@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=aravind.iddamsetty@intel.com \
--cc=arvind.yadav@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=mallesh.koujalagi@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=nitin.r.gote@intel.com \
--cc=raag.jadav@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=syed.abdul.muqthyar.ahmed@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox