Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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