Skip to contentSkip to conversation

Fix issues with ARM Processor CPER records

PATCH In review Mauro Carvalho Chehab 4 participants 11 messages Sep 4, 2024 – Jun 21, 2025

Subsystems (6)
Documentation ACPI EFI EDAC-core +2 more subsystems
lore
Share & tools
lore
#0 lore raw

v3 cover Fix issues with ARM Processor CPER records

This is needed for both kernelspace and userspace properly handle ARM processor CPER events.

Patch 1 of this series fix the UEFI 2.6+ implementation of the ARM trace event, as the original implementation was incomplete. Changeset e9279e83ad1f ("trace, ras: add ARM processor error trace event") added such event, but it reports only some fields of the CPER record defined on UEFI 2.6+ appendix N, table N.16. Those are not enough actually parse such events on userspace, as not even the event type is exported.

Patch 2 fixes a compilation breakage when W=1;

Patch 3 adds a new helper function to be used by cper and ghes drivers to display CPER bitmaps;

Patch 4 fixes CPER logic according with UEFI 2.9A errata. Before it, there was no description about how processor type field was encoded. The errata defines it as a bitmask, and provides the information about how it should be encoded.

Patch 5 adds CPER functions to Kernel-doc.

This series was validated with the help of an ARM EINJ code for QEMU:

https://gitlab.com/mchehab_kernel/qemu/-/tree/qemu_submission

$ scripts/ghes_inject.py -d arm -p 0xdeadbeef -t cache,bus,micro-arch
[   11.094205] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0
[   11.095009] {1}[Hardware Error]: event severity: recoverable
[   11.095486] {1}[Hardware Error]:  Error 0, type: recoverable
[   11.096090] {1}[Hardware Error]:   section_type: ARM processor error
[   11.096399] {1}[Hardware Error]:   MIDR: 0x00000000000f0510
[   11.097135] {1}[Hardware Error]:   Multiprocessor Affinity Register (MPIDR): 0x0000000080000000
[   11.097811] {1}[Hardware Error]:   running state: 0x0
[   11.098193] {1}[Hardware Error]:   Power State Coordination Interface state: 0
[   11.098699] {1}[Hardware Error]:   Error info structure 0:
[   11.099174] {1}[Hardware Error]:   num errors: 2
[   11.099682] {1}[Hardware Error]:    error_type: 0x1a: cache error|bus error|micro-architectural error
[   11.100150] {1}[Hardware Error]:    physical fault address: 0x00000000deadbeef
[   11.111214] Memory failure: 0xdeadb: recovery action for free buddy page: Recovered

-

I also tested the ghes and cper reports both with and without this change, using different versions of rasdaemon, with and without support for the extended trace event. Those are a summary of the test results:

- adding more fields to the trace events didn't break userspace API:
both versions of rasdaemon handled it;

- the rasdaemon patches to handle the new trace report was missing a backward-compatibility logic. I fixed already. So, rasdaemon can now handle both old and new trace events.

Btw, rasdaemon has gained support for the extended trace since its version 0.5.8 (released in 2021). I didn't saw any issues there complain about troubles on it, so either distros used on ARM servers are using an old version of rasdaemon, or they're carrying on the trace event changes as well.

---

v3:
- history of patch 1 improved with a chain of co-developed-by;
- add a better description and an example on patch 3;
- use BIT_ULL() on patch 3;
- add a missing include on patch 4.

v2:
- removed an uneeded patch adding #ifdef for CONFIG_ARM/ARM64;
- cper_bits_to_str() now returns the number of chars filled at the buffer;
- did a cosmetic (blank lines) improvement at include/linux/ras.h;
- arm_event trace dynamic arrays renamed to pei_buf/ctx_buf/oem_buf.

Jason Tian (1):
RAS: Report all ARM processor CPER information to userspace

Mauro Carvalho Chehab (4):
efi/cper: Adjust infopfx size to accept an extra space efi/cper: Add a new helper function to print bitmasks efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
docs: efi: add CPER functions to driver-api

 .../driver-api/firmware/efi/index.rst         | 11 +++-
 drivers/acpi/apei/ghes.c                      | 27 ++++----
 drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
 drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
 drivers/ras/ras.c                             | 41 +++++++++++-
 include/linux/cper.h                          | 12 ++--
 include/linux/ras.h                           | 16 ++++-
 include/ras/ras_event.h                       | 48 ++++++++++++--
 8 files changed, 210 insertions(+), 59 deletions(-)
Signature · 1 line
2.46.0
#1 lore raw

PATCH v3 1/5 RAS: Report all ARM processor CPER information to userspace

From: Jason Tian <[email protected]>

The ARM processor CPER record was added at UEFI 2.6, and hasn't any changes up to UEFI 2.10 on its struct.

Yet, the original arm_event trace code added on changeset e9279e83ad1f ("trace, ras: add ARM processor error trace event") is incomplete, as it only traces some fields of UAPI 2.6 table N.16, not exporting at all any information from tables N.17 to N.29 of the record.

This is not enough for user to take appropriate action or to log what exactly happened.

According to UEFI_2_9 specification chapter N2.4.4, the ARM processor error section includes:

- several (ERR_INFO_NUM) ARM processor error information structures (Tables N.17 to N.20);
- several (CONTEXT_INFO_NUM) ARM processor context information structures (Tables N.21 to N.29);
- several vendor specific error information structures. The size is given by Section Length minus the size of the other fields.

In addition to those data, it also exports two fields that are parsed by the GHES driver when firmware reports it, e. g.:

- error severity
- CPU logical index

Report all of these information to userspace via trace uAPI, So that userspace can properly record the error and take decisions related to CPU core isolation according to error severity and other info.

The updated ARM trace event now contains the following fields:

====================================== =============================
UEFI field on table N.16 ARM Processor trace fields
====================================== =============================
Validation handled when filling data for
affinity MPIDR and running state.
ERR_INFO_NUM pei_len
CONTEXT_INFO_NUM ctx_len
Section Length indirectly reported by
pei_len, ctx_len and oem_len
Error affinity level affinity
MPIDR_EL1 mpidr
MIDR_EL1 midr
Running State running_state
PSCI State psci_state
Processor Error Information Structure pei_err - count at pei_len
Processor Context ctx_err- count at ctx_len
Vendor Specific Error Info oem - count at oem_len
====================================== =============================

It should be noticed that decoding of tables N.17 to N.29, if needed, will be handled on userspace. That gives more flexibility, as there won't be any need to flood the Kernel with micro-architecture specific error decoding).
Also, decoding the other fields require a complex logic, and should be done for each of the several values inside the record field. So, let userspace daemons like rasdaemon decode them, parsing such tables and having vendor-specific micro-architecture-specific decoders.

[mchehab: modified description, solved merge conflicts and fixed coding style]
Fixes e9279e83ad1f ("trace, ras: add ARM processor error trace event")
---
 drivers/acpi/apei/ghes.c | 11 ++++-----
 drivers/ras/ras.c        | 41 ++++++++++++++++++++++++++++++++--
 include/linux/ras.h      | 16 +++++++++++---
 include/ras/ras_event.h  | 48 +++++++++++++++++++++++++++++++++++-----
 4 files changed, 99 insertions(+), 17 deletions(-)
drivers/acpi/apei/ghes.c +4 -7
index 623cc0cb4a65..06d9351a9abc 100644
@@ -529,7 +529,7 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata,
 }
 
 static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,
-				       int sev, bool sync)
+				     int sev, bool sync)
 {
 	struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata);
 	int flags = sync ? MF_ACTION_REQUIRED : 0;
@@ -537,9 +537,8 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,
 	int sec_sev, i;
 	char *p;
 
-	log_arm_hw_error(err);
-
 	sec_sev = ghes_severity(gdata->error_severity);
+	log_arm_hw_error(err, sec_sev);
 	if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE)
 		return false;
 
@@ -773,11 +772,9 @@ static bool ghes_do_proc(struct ghes *ghes,
 
 			arch_apei_report_mem_error(sev, mem_err);
 			queued = ghes_handle_memory_failure(gdata, sev, sync);
-		}
-		else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
+		} else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
 			ghes_handle_aer(gdata);
-		}
-		else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) {
+		} else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) {
 			queued = ghes_handle_arm_hw_error(gdata, sev, sync);
 		} else if (guid_equal(sec_type, &CPER_SEC_CXL_GEN_MEDIA_GUID)) {
 			struct cxl_cper_event_rec *rec = acpi_hest_get_payload(gdata);
drivers/ras/ras.c +39 -2

48 lines not on this page · raw message

include/linux/ras.h +13 -3
index a64182bc72ad..df444492b434 100644
@@ -24,8 +24,7 @@ int __init parse_cec_param(char *str);
 void log_non_standard_event(const guid_t *sec_type,
 			    const guid_t *fru_id, const char *fru_text,
 			    const u8 sev, const u8 *err, const u32 len);
-void log_arm_hw_error(struct cper_sec_proc_arm *err);
-
+void log_arm_hw_error(struct cper_sec_proc_arm *err, const u8 sev);
 #else
 static inline void
 log_non_standard_event(const guid_t *sec_type,
@@ -33,7 +32,7 @@ log_non_standard_event(const guid_t *sec_type,
 		       const u8 sev, const u8 *err, const u32 len)
 { return; }
 static inline void
-log_arm_hw_error(struct cper_sec_proc_arm *err) { return; }
+log_arm_hw_error(struct cper_sec_proc_arm *err, const u8 sev) { return; }
 #endif
 
 struct atl_err {
@@ -53,4 +52,15 @@ static inline unsigned long
 amd_convert_umc_mca_addr_to_sys_addr(struct atl_err *err) { return -EINVAL; }
 #endif /* CONFIG_AMD_ATL */
 
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+#include <asm/smp_plat.h>
+/*
+ * Include ARM specific SMP header which provides a function mapping mpidr to
+ * cpu logical index.
+ */
+#define GET_LOGICAL_INDEX(mpidr) get_logical_index(mpidr & MPIDR_HWID_BITMASK)
+#else
+#define GET_LOGICAL_INDEX(mpidr) -EINVAL
+#endif /* CONFIG_ARM || CONFIG_ARM64 */
+
 #endif /* __RAS_H__ */
include/ras/ras_event.h +43 -5

72 lines not on this page · raw message

Signature · 1 line
2.46.0
#3 lore raw

PATCH v3 2/5 efi/cper: Adjust infopfx size to accept an extra space

In reply to Mauro Carvalho Chehab

Compiling with W=1 with werror enabled produces an error:

drivers/firmware/efi/cper-arm.c: In function ‘cper_print_proc_arm’:
drivers/firmware/efi/cper-arm.c:298:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx);
| ^
drivers/firmware/efi/cper-arm.c:298:25: note: ‘snprintf’ output between 2 and 65 bytes into a destination of size 64

  298 |                         snprintf(infopfx, sizeof(infopfx), "%s ", newpfx);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As the logic there adds an space at the end of infopx buffer. Add an extra space to avoid such warning.

---
 drivers/firmware/efi/cper-arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/efi/cper-arm.c +1 -1
index fa9c1c3bf168..eb7ee6af55f2 100644
@@ -240,7 +240,7 @@ void cper_print_proc_arm(const char *pfx,
 	int i, len, max_ctx_type;
 	struct cper_arm_err_info *err_info;
 	struct cper_arm_ctx_info *ctx_info;
-	char newpfx[64], infopfx[64];
+	char newpfx[64], infopfx[ARRAY_SIZE(newpfx) + 1];
 
 	printk("%sMIDR: 0x%016llx\n", pfx, proc->midr);
 
Signature · 1 line
2.46.0
#4 lore raw

PATCH v3 3/5 efi/cper: Add a new helper function to print bitmasks

In reply to Mauro Carvalho Chehab

Add a helper function to print a string with names associated to each bit field.

A typical example is:

	const char * const bits[] = {
		"bit 3 name",
		"bit 4 name",
		"bit 5 name",
	};
	char str[120];
        unsigned int bitmask = BIT(3) | BIT(5);

	#define MASK  GENMASK(5,3)

	cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask),
			 bits, ARRAY_SIZE(bits));

The above code fills string "str" with "bit 3 name|bit 5 name".

Reviewed-by; Jonathan Cameron <[email protected]>

---
 drivers/firmware/efi/cper.c | 60 +++++++++++++++++++++++++++++++++++++
 include/linux/cper.h        |  2 ++
 2 files changed, 62 insertions(+)
drivers/firmware/efi/cper.c +60 -0
index 7d2cdd9e2227..f60fe7367e3b 100644
@@ -12,6 +12,7 @@
  * Specification version 2.4.
  */
 
+#include <linux/bitmap.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/time.h>
@@ -106,6 +107,65 @@ void cper_print_bits(const char *pfx, unsigned int bits,
 		printk("%s\n", buf);
 }
 
+/**
+ * cper_bits_to_str - return a string for set bits
+ * @buf: buffer to store the output string
+ * @buf_size: size of the output string buffer
+ * @bits: bit mask
+ * @strs: string array, indexed by bit position
+ * @strs_size: size of the string array: @strs
+ *
+ * Add to @buf the bitmask in hexadecimal. Then, for each set bit in @bits,
+ * add the corresponding string describing the bit in @strs to @buf.
+ *
+ * A typical example is::
+ *
+ *	const char * const bits[] = {
+ *		"bit 3 name",
+ *		"bit 4 name",
+ *		"bit 5 name",
+ *	};
+ *	char str[120];
+ *	unsigned int bitmask = BIT(3) | BIT(5);
+ *	#define MASK GENMASK(5,3)
+ *
+ *	cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask),
+ *			 bits, ARRAY_SIZE(bits));
+ *
+ * The above code fills the string ``str`` with ``bit 3 name|bit 5 name``.
+ *
+ * Return: number of bytes stored or an error code if lower than zero.
+ */
+int cper_bits_to_str(char *buf, int buf_size, unsigned long bits,
+		     const char * const strs[], unsigned int strs_size)
+{
+	int len = buf_size;
+	char *str = buf;
+	int i, size;
+
+	*buf = '\0';
+
+	for_each_set_bit(i, &bits, strs_size) {
+		if (!(bits & BIT_ULL(i)))
+			continue;
+
+		if (*buf && len > 0) {
+			*str = '|';
+			len--;
+			str++;
+		}
+
+		size = strscpy(str, strs[i], len);
+		if (size < 0)
+			return size;
+
+		len -= size;
+		str += size;
+	}
+	return len - buf_size;
+}
+EXPORT_SYMBOL_GPL(cper_bits_to_str);
+
 static const char * const proc_type_strs[] = {
 	"IA32/X64",
 	"IA64",
include/linux/cper.h +2 -0
index 265b0f8fc0b3..25858a7608b7 100644
@@ -584,6 +584,8 @@ const char *cper_mem_err_type_str(unsigned int);
 const char *cper_mem_err_status_str(u64 status);
 void cper_print_bits(const char *prefix, unsigned int bits,
 		     const char * const strs[], unsigned int strs_size);
+int cper_bits_to_str(char *buf, int buf_size, unsigned long bits,
+		     const char * const strs[], unsigned int strs_size);
 void cper_mem_err_pack(const struct cper_sec_mem_err *,
 		       struct cper_mem_err_compact *);
 const char *cper_mem_err_unpack(struct trace_seq *,
Signature · 1 line
2.46.0
#5 lore raw

PATCH v3 4/5 efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs

In reply to Mauro Carvalho Chehab

Up to UEFI spec 2.9, the type byte of CPER struct for ARM processor was defined simply as:

Type at byte offset 4:

- Cache error
- TLB Error
- Bus Error
- Micro-architectural Error
All other values are reserved

Yet, there was no information about how this would be encoded.

Spec 2.9A errata corrected it by defining:

- Bit 1 - Cache Error
- Bit 2 - TLB Error
- Bit 3 - Bus Error
- Bit 4 - Micro-architectural Error
All other values are reserved

That actually aligns with the values already defined on older versions at N.2.4.1. Generic Processor Error Section.

Spec 2.10 also preserve the same encoding as 2.9A.

Adjust CPER and GHES handling code for both generic and ARM processors to properly handle UEFI 2.9A and 2.10 encoding.

---
 drivers/acpi/apei/ghes.c        | 16 +++++++----
 drivers/firmware/efi/cper-arm.c | 50 ++++++++++++++++-----------------
 include/linux/cper.h            | 10 +++----
 3 files changed, 39 insertions(+), 37 deletions(-)
drivers/acpi/apei/ghes.c +10 -6
index 06d9351a9abc..ae608f5c1257 100644
@@ -22,6 +22,7 @@
 #include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/acpi.h>
+#include <linux/bitfield.h>
 #include <linux/io.h>
 #include <linux/interrupt.h>
 #include <linux/timer.h>
@@ -533,6 +534,7 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,
 {
 	struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata);
 	int flags = sync ? MF_ACTION_REQUIRED : 0;
+	char error_type[120];
 	bool queued = false;
 	int sec_sev, i;
 	char *p;
@@ -545,9 +547,8 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,
 	p = (char *)(err + 1);
 	for (i = 0; i < err->err_info_num; i++) {
 		struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p;
-		bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR);
+		bool is_cache = err_info->type & CPER_ARM_CACHE_ERROR;
 		bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR);
-		const char *error_type = "unknown error";
 
 		/*
 		 * The field (err_info->error_info & BIT(26)) is fixed to set to
@@ -561,12 +562,15 @@ static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,
 			continue;
 		}
 
-		if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs))
-			error_type = cper_proc_error_type_strs[err_info->type];
+		cper_bits_to_str(error_type, sizeof(error_type),
+				 FIELD_GET(CPER_ARM_ERR_TYPE_MASK, err_info->type),
+				 cper_proc_error_type_strs,
+				 ARRAY_SIZE(cper_proc_error_type_strs));
 
 		pr_warn_ratelimited(FW_WARN GHES_PFX
-				    "Unhandled processor error type: %s\n",
-				    error_type);
+				    "Unhandled processor error type 0x%02x: %s%s\n",
+				    err_info->type, error_type,
+				    (err_info->type & ~CPER_ARM_ERR_TYPE_MASK) ? " with reserved bit(s)" : "");
 		p += err_info->length;
 	}
 
drivers/firmware/efi/cper-arm.c +24 -26

97 lines not on this page · raw message

include/linux/cper.h +5 -5
index 25858a7608b7..3670b866ac11 100644
@@ -293,11 +293,11 @@ enum {
 #define CPER_ARM_INFO_FLAGS_PROPAGATED		BIT(2)
 #define CPER_ARM_INFO_FLAGS_OVERFLOW		BIT(3)
 
-#define CPER_ARM_CACHE_ERROR			0
-#define CPER_ARM_TLB_ERROR			1
-#define CPER_ARM_BUS_ERROR			2
-#define CPER_ARM_VENDOR_ERROR			3
-#define CPER_ARM_MAX_TYPE			CPER_ARM_VENDOR_ERROR
+#define CPER_ARM_ERR_TYPE_MASK			GENMASK(4,1)
+#define CPER_ARM_CACHE_ERROR			BIT(1)
+#define CPER_ARM_TLB_ERROR			BIT(2)
+#define CPER_ARM_BUS_ERROR			BIT(3)
+#define CPER_ARM_VENDOR_ERROR			BIT(4)
 
 #define CPER_ARM_ERR_VALID_TRANSACTION_TYPE	BIT(0)
 #define CPER_ARM_ERR_VALID_OPERATION_TYPE	BIT(1)
Signature · 1 line
2.46.0
#6 lore raw

PATCH v3 5/5 docs: efi: add CPER functions to driver-api

In reply to Mauro Carvalho Chehab

There are two kernel-doc like descriptions at cper, which is used by other parts of cper and on ghes driver. They both have kernel-doc like descriptions.

Change the tags for them to be actual kernel-doc tags and add them to the driver-api documentaion at the UEFI section.

---
 Documentation/driver-api/firmware/efi/index.rst | 11 ++++++++---
 drivers/firmware/efi/cper.c                     |  2 +-
 2 files changed, 9 insertions(+), 4 deletions(-)
Documentation/driver-api/firmware/efi/index.rst +8 -3
index 4fe8abba9fc6..5a6b6229592c 100644
@@ -1,11 +1,16 @@
 .. SPDX-License-Identifier: GPL-2.0
 
-============
-UEFI Support
-============
+====================================================
+Unified Extensible Firmware Interface (UEFI) Support
+====================================================
 
 UEFI stub library functions
 ===========================
 
 .. kernel-doc:: drivers/firmware/efi/libstub/mem.c
    :internal:
+
+UEFI Common Platform Error Record (CPER) functions
+==================================================
+
+.. kernel-doc:: drivers/firmware/efi/cper.c
drivers/firmware/efi/cper.c +1 -1
index f60fe7367e3b..4d2dfcc746b6 100644
@@ -70,7 +70,7 @@ const char *cper_severity_str(unsigned int severity)
 }
 EXPORT_SYMBOL_GPL(cper_severity_str);
 
-/*
+/**
  * cper_print_bits - print strings for set bits
  * @pfx: prefix for each line, including log level and prefix string
  * @bits: bit mask
Signature · 1 line
2.46.0
maintainer Reviewed-by Jonathan Cameron Tested-by Shiju Jose on v3 1/5
#2 lore raw

Re: [PATCH v3 1/5] RAS: Report all ARM processor CPER information to userspace

In reply to Mauro Carvalho Chehab
Quoted 4 lines · Mauro Carvalho Chehab

From: Jason Tian <[email protected]>

The ARM processor CPER record was added at UEFI 2.6, and hasn't any changes up to UEFI 2.10 on its struct.

Did some fixups to the commit message, please use it in your next submission.

There was also this typo:

From: Jason Tian <[email protected]>

RAS: Report all ARM processor CPER information to userspace

The ARM processor CPER record was added in UEFI v2.6 and remained unchanged up to v2.10.

Yet, the original arm_event trace code added by

e9279e83ad1f ("trace, ras: add ARM processor error trace event")

is incomplete, as it only traces some fields of UAPI 2.6 table N.16, not exporting any information from tables N.17 to N.29 of the record.

This is not enough for the user to be able to figure out what has exactly happened or to take appropriate action.

According to the UEFI v2.9 specification chapter N2.4.4, the ARM processor error section includes:

- several (ERR_INFO_NUM) ARM processor error information structures (Tables N.17 to N.20);
- several (CONTEXT_INFO_NUM) ARM processor context information structures (Tables N.21 to N.29);
- several vendor specific error information structures. The size is given by Section Length minus the size of the other fields.

In addition, it also exports two fields that are parsed by the GHES driver when firmware reports it, e.g.:

- error severity
- CPU logical index

Report all of these information to userspace via a the ARM tracepoint so that userspace can properly record the error and take decisions related to CPU core isolation according to error severity and other info.

The updated ARM trace event now contains the following fields:

====================================== =============================
UEFI field on table N.16 ARM Processor trace fields
====================================== =============================
Validation handled when filling data for
affinity MPIDR and running state.
ERR_INFO_NUM pei_len
CONTEXT_INFO_NUM ctx_len
Section Length indirectly reported by
pei_len, ctx_len and oem_len
Error affinity level affinity
MPIDR_EL1 mpidr
MIDR_EL1 midr
Running State running_state
PSCI State psci_state
Processor Error Information Structure pei_err - count at pei_len
Processor Context ctx_err- count at ctx_len
Vendor Specific Error Info oem - count at oem_len
====================================== =============================

It should be noted that decoding of tables N.17 to N.29, if needed, will be handled in userspace. That gives more flexibility, as there won't be any need to flood the kernel with micro-architecture specific error decoding.

Also, decoding the other fields require a complex logic, and should be done for each of the several values inside the record field. So, let userspace daemons like rasdaemon decode them, parsing such tables and having vendor-specific micro-architecture-specific decoders.

[mchehab: modified description, solved merge conflicts and fixed coding style]

Quoted 5 lines
 drivers/acpi/apei/ghes.c | 11 ++++-----
 drivers/ras/ras.c        | 41 ++++++++++++++++++++++++++++++++--
 include/linux/ras.h      | 16 +++++++++++---
 include/ras/ras_event.h  | 48 +++++++++++++++++++++++++++++++++++-----
 4 files changed, 99 insertions(+), 17 deletions(-)

Also, some cleanups ontop:

drivers/ras/ras.c +2 -2
index 6a0480c76e19..179b1744df71 100644
@@ -70,14 +70,14 @@ void log_arm_hw_error(struct cper_sec_proc_arm *err, const u8 sev)
 	err_info = (struct cper_arm_err_info *)(err + 1);
 	ctx_info = (struct cper_arm_ctx_info *)(err_info + err->err_info_num);
 	ctx_err = (u8 *)ctx_info;
+
 	for (n = 0; n < err->context_info_num; n++) {
 		sz = sizeof(struct cper_arm_ctx_info) + ctx_info->size;
 		ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz);
 		ctx_len += sz;
 	}
 
-	vsei_len = err->section_length - (sizeof(struct cper_sec_proc_arm) +
-					  pei_len + ctx_len);
+	vsei_len = err->section_length - (sizeof(struct cper_sec_proc_arm) + pei_len + ctx_len);
 	if (vsei_len < 0) {
 		pr_warn(FW_BUG "section length: %d\n", err->section_length);
 		pr_warn(FW_BUG "section length is too small\n");
include/linux/ras.h +2 -2
index df444492b434..468941bfe855 100644
@@ -55,8 +55,8 @@ amd_convert_umc_mca_addr_to_sys_addr(struct atl_err *err) { return -EINVAL; }
 #if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
 #include <asm/smp_plat.h>
 /*
- * Include ARM specific SMP header which provides a function mapping mpidr to
- * cpu logical index.
+ * Include ARM-specific SMP header which provides a function mapping mpidr to
+ * CPU logical index.
  */
 #define GET_LOGICAL_INDEX(mpidr) get_logical_index(mpidr & MPIDR_HWID_BITMASK)
 #else

Thx.

Signature · 4 lines
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
maintainer Acked-by on the v3 series
#7 lore raw
In reply to Mauro Carvalho Chehab
Quoted 9 lines · Mauro Carvalho Chehab

Jason Tian (1):
RAS: Report all ARM processor CPER information to userspace

Mauro Carvalho Chehab (4):
efi/cper: Adjust infopfx size to accept an extra space efi/cper: Add a new helper function to print bitmasks efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
docs: efi: add CPER functions to driver-api

Quoted 9 lines
 .../driver-api/firmware/efi/index.rst         | 11 +++-
 drivers/acpi/apei/ghes.c                      | 27 ++++----
 drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
 drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
 drivers/ras/ras.c                             | 41 +++++++++++-
 include/linux/cper.h                          | 12 ++--
 include/linux/ras.h                           | 16 ++++-
 include/ras/ras_event.h                       | 48 ++++++++++++--
 8 files changed, 210 insertions(+), 59 deletions(-)

With the issues to patch 1 fixed:

I'm presuming this'll go through Ard's tree. Alternatively, I can pick it up too with Ard's ack.

Thx.

Signature · 4 lines
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
maintainer
#8 lore raw
Quoted 21 lines · Borislav Petkov
Quoted 9 lines · Mauro Carvalho Chehab

Jason Tian (1):
RAS: Report all ARM processor CPER information to userspace

Mauro Carvalho Chehab (4):
efi/cper: Adjust infopfx size to accept an extra space efi/cper: Add a new helper function to print bitmasks efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
docs: efi: add CPER functions to driver-api

Quoted 9 lines
 .../driver-api/firmware/efi/index.rst         | 11 +++-
 drivers/acpi/apei/ghes.c                      | 27 ++++----
 drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
 drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
 drivers/ras/ras.c                             | 41 +++++++++++-
 include/linux/cper.h                          | 12 ++--
 include/linux/ras.h                           | 16 ++++-
 include/ras/ras_event.h                       | 48 ++++++++++++--
 8 files changed, 210 insertions(+), 59 deletions(-)
Quoted 7 lines

With the issues to patch 1 fixed:

I'm presuming this'll go through Ard's tree. Alternatively, I can pick it up too with Ard's ack.

Either works for me.

Mauro: please put all maintainers on cc of the code you are touching - thanks.

#9 lore raw
Quoted 26 lines · Ard Biesheuvel
Quoted 25 lines · Borislav Petkov
Quoted 9 lines · Mauro Carvalho Chehab

Jason Tian (1):
RAS: Report all ARM processor CPER information to userspace

Mauro Carvalho Chehab (4):
efi/cper: Adjust infopfx size to accept an extra space efi/cper: Add a new helper function to print bitmasks efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
docs: efi: add CPER functions to driver-api

Quoted 9 lines
 .../driver-api/firmware/efi/index.rst         | 11 +++-
 drivers/acpi/apei/ghes.c                      | 27 ++++----
 drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
 drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
 drivers/ras/ras.c                             | 41 +++++++++++-
 include/linux/cper.h                          | 12 ++--
 include/linux/ras.h                           | 16 ++++-
 include/ras/ras_event.h                       | 48 ++++++++++++--
 8 files changed, 210 insertions(+), 59 deletions(-)

With the issues to patch 1 fixed:

Quoted 7 lines
Quoted 3 lines

I'm presuming this'll go through Ard's tree. Alternatively, I can pick it up too with Ard's ack.

Either works for me.

Mauro: please put all maintainers on cc of the code you are touching - thanks.

What can I do to help this patch move forward? I noticed it needs to be rebased as of kernel v6.15.

Would it be helpful if I were to rebase, add all the maintainers to the cc, and resubmit ?

I did rebase to v6.15 and tested. Everything still seems good to go.

maintainer
#10 lore raw
Quoted 36 lines · Daniel Ferguson
Quoted 32 lines · Ard Biesheuvel
Quoted 21 lines · Borislav Petkov
Quoted 9 lines · Mauro Carvalho Chehab

Jason Tian (1):
RAS: Report all ARM processor CPER information to userspace

Mauro Carvalho Chehab (4):
efi/cper: Adjust infopfx size to accept an extra space efi/cper: Add a new helper function to print bitmasks efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
docs: efi: add CPER functions to driver-api

Quoted 9 lines
 .../driver-api/firmware/efi/index.rst         | 11 +++-
 drivers/acpi/apei/ghes.c                      | 27 ++++----
 drivers/firmware/efi/cper-arm.c               | 52 ++++++++--------
 drivers/firmware/efi/cper.c                   | 62 ++++++++++++++++++-
 drivers/ras/ras.c                             | 41 +++++++++++-
 include/linux/cper.h                          | 12 ++--
 include/linux/ras.h                           | 16 ++++-
 include/ras/ras_event.h                       | 48 ++++++++++++--
 8 files changed, 210 insertions(+), 59 deletions(-)
Quoted 7 lines

With the issues to patch 1 fixed:

I'm presuming this'll go through Ard's tree. Alternatively, I can pick it up too with Ard's ack.

Either works for me.

Quoted 8 lines
Quoted 1 line

Mauro: please put all maintainers on cc of the code you are touching - thanks.

What can I do to help this patch move forward? I noticed it needs to be rebased as of kernel v6.15.

Would it be helpful if I were to rebase, add all the maintainers to the cc, and resubmit ?

Yes, please. And make sure you incorporate Boris's feedback on patch #1 and apply his conditional ack.

Thanks,