Add L1 and L2 error detection for A53, A57 and A72

From: Sascha Hauer <[email protected]>

The Cortex A53, A57 and A72 cores have error detection capabilities for the L1/L2 Caches, this patch adds a driver for them. The selected errors to detect/report have compatible bit assignments concerning CPU/L2 memory error syndrome registers.

Unfortunately there is no robust way to inject errors into the caches, so this driver doesn't contain any code to actually test it. It has been tested though with code taken from an older version [1] of this driver. For reasons stated in thread [1], the error injection code is not suitable for mainline, so it is removed from the driver.

[1] https://lore.kernel.org/all/[email protected]/#t

Signed-off-by Sascha Hauer <[email protected]>

Co-developed-by Vijay Balakrishna <[email protected]>

Signed-off-by Vijay Balakrishna <[email protected]>

---
 drivers/edac/Kconfig              |   9 ++
 drivers/edac/Makefile             |   1 +
 drivers/edac/cortex_arm64_l1_l2.c | 225 ++++++++++++++++++++++++++++++
 3 files changed, 235 insertions(+)
 create mode 100644 drivers/edac/cortex_arm64_l1_l2.c

drivers/edac/Kconfig +9 -0

index 19ad3c3b675d..20c15a18437f 100644
@@ -576,4 +576,13 @@ config EDAC_LOONGSON
 	  errors (CE) only. Loongson-3A5000/3C5000/3D5000/3A6000/3C6000
 	  are compatible.
 
+config EDAC_CORTEX_ARM64_L1_L2
+	tristate "ARM Cortex A72/A57/A53"
+	depends on ARM64
+	help
+	  Support for L1/L2 cache error detection is provided for ARM Cortex
+	  A72, A57, and A53 processors. The selected subset of errors is common
+	  across these three MPCore processors, featuring compatible bit
+	  assignments in their CPU/L2 memory error syndrome registers.
+
 endif # EDAC

drivers/edac/Makefile +1 -0

index a8f2d8f6c894..157062410e61 100644
@@ -88,3 +88,4 @@ obj-$(CONFIG_EDAC_NPCM)			+= npcm_edac.o
 obj-$(CONFIG_EDAC_ZYNQMP)		+= zynqmp_edac.o
 obj-$(CONFIG_EDAC_VERSAL)		+= versal_edac.o
 obj-$(CONFIG_EDAC_LOONGSON)		+= loongson_edac.o
+obj-$(CONFIG_EDAC_CORTEX_ARM64_L1_L2)	+= cortex_arm64_l1_l2.o

drivers/edac/cortex_arm64_l1_l2.c new file +82 -0

new file mode 100644
index 000000000000..2ffe20212acb
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cortex A72, A57 and A53 EDAC L1 and L2 cache error detection
+ *
+ * Copyright (c) 2020 Pengutronix, Sascha Hauer <[email protected]>
+ *
+ * Based on Code from:
+ * Copyright (c) 2018, NXP Semiconductor
+ * Author: York Sun <[email protected]>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_device.h>
+#include <linux/bitfield.h>
+#include <asm/smp_plat.h>
+
+#include "edac_module.h"
+
+#define DRVNAME				"cortex-arm64-edac"
+
+#define CPUMERRSR_EL1_RAMID		GENMASK(30, 24)
+
+#define CPUMERRSR_EL1_VALID		BIT(31)
+#define CPUMERRSR_EL1_FATAL		BIT(63)
+
+#define L1_I_TAG_RAM			0x00
+#define L1_I_DATA_RAM			0x01
+#define L1_D_TAG_RAM			0x08
+#define L1_D_DATA_RAM			0x09
+#define TLB_RAM				0x18
+
+#define L2MERRSR_EL1_CPUID_WAY	GENMASK(21, 18)
+
+#define L2MERRSR_EL1_VALID		BIT(31)
+#define L2MERRSR_EL1_FATAL		BIT(63)
+
+struct merrsr {
+	u64 cpumerr;
+	u64 l2merr;
+};
+
+#define MESSAGE_SIZE 64
+
+#define SYS_CPUMERRSR_EL1			sys_reg(3, 1, 15, 2, 2)
+#define SYS_L2MERRSR_EL1			sys_reg(3, 1, 15, 2, 3)
+
+static struct cpumask compat_mask;
+
+static void report_errors(struct edac_device_ctl_info *edac_ctl, int cpu,
+			  struct merrsr *merrsr)
+{
+	char msg[MESSAGE_SIZE];
+	u64 cpumerr = merrsr->cpumerr;
+	u64 l2merr = merrsr->l2merr;
+
+	if (cpumerr & CPUMERRSR_EL1_VALID) {
+		const char *str;
+		bool fatal = cpumerr & CPUMERRSR_EL1_FATAL;
+
+		switch (FIELD_GET(CPUMERRSR_EL1_RAMID, cpumerr)) {
+		case L1_I_TAG_RAM:
+			str = "L1-I Tag RAM";
+			break;
+		case L1_I_DATA_RAM:
+			str = "L1-I Data RAM";
+			break;
+		case L1_D_TAG_RAM:
+			str = "L1-D Tag RAM";
+			break;
+		case L1_D_DATA_RAM:
+			str = "L1-D Data RAM";
+			break;
+		case TLB_RAM:
+			str = "TLB RAM";
+			break;
+		default:
+			str = "Unspecified";
+			break;
+		}
+

drivers/edac/cortex_arm64_l1_l2.c new file +93 -0

+	}
+
+	if (l2merr & L2MERRSR_EL1_VALID) {
+		bool fatal = l2merr & L2MERRSR_EL1_FATAL;
+
+		snprintf(msg, MESSAGE_SIZE, "L2 %s error(s) on CPU %d CPUID/WAY 0x%x",
+			 fatal ? "fatal" : "correctable", cpu,
+			 FIELD_GET(L2MERRSR_EL1_CPUID_WAY, l2merr));
+		if (fatal)
+			edac_device_handle_ue(edac_ctl, cpu, 1, msg);
+		else
+			edac_device_handle_ce(edac_ctl, cpu, 1, msg);
+
+		write_sysreg_s(0, SYS_L2MERRSR_EL1);
+		isb();
+	}
+}
+
+static void read_errors(void *data)
+{
+	struct merrsr *merrsr = data;
+
+	merrsr->cpumerr = read_sysreg_s(SYS_CPUMERRSR_EL1);
+	merrsr->l2merr = read_sysreg_s(SYS_L2MERRSR_EL1);
+}
+
+static void cortex_arm64_edac_check(struct edac_device_ctl_info *edac_ctl)
+{
+	struct merrsr merrsr;
+	int cpu;
+
+	for_each_cpu_and(cpu, cpu_online_mask, &compat_mask) {
+		smp_call_function_single(cpu, read_errors, &merrsr, true);
+		report_errors(edac_ctl, cpu, &merrsr);
+	}
+}
+
+static int cortex_arm64_edac_probe(struct platform_device *pdev)
+{
+	struct edac_device_ctl_info *edac_ctl;
+	struct device *dev = &pdev->dev;
+	int rc;
+
+	edac_ctl = edac_device_alloc_ctl_info(0, "cpu",
+					      num_possible_cpus(), "L", 2, 1, NULL, 0,
+					      edac_device_alloc_index());
+	if (!edac_ctl)
+		return -ENOMEM;
+
+	edac_ctl->edac_check = cortex_arm64_edac_check;
+	edac_ctl->dev = dev;
+	edac_ctl->mod_name = dev_name(dev);
+	edac_ctl->dev_name = dev_name(dev);
+	edac_ctl->ctl_name = DRVNAME;
+	dev_set_drvdata(dev, edac_ctl);
+
+	rc = edac_device_add_device(edac_ctl);
+	if (rc)
+		goto out_dev;
+
+	return 0;
+
+out_dev:
+	edac_device_free_ctl_info(edac_ctl);
+
+	return rc;
+}
+
+static int cortex_arm64_edac_remove(struct platform_device *pdev)
+{
+	struct edac_device_ctl_info *edac_ctl = dev_get_drvdata(&pdev->dev);
+
+	edac_device_del_device(edac_ctl->dev);
+	edac_device_free_ctl_info(edac_ctl);
+
+	return 0;
+}
+
+static const struct of_device_id cortex_arm64_edac_of_match[] = {
+	{ .compatible = "arm,cortex-a53" },
+	{ .compatible = "arm,cortex-a57" },
+	{ .compatible = "arm,cortex-a72" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, cortex_arm64_edac_of_match);
+
+static struct platform_driver cortex_arm64_edac_driver = {
+	.probe = cortex_arm64_edac_probe,
+	.remove = cortex_arm64_edac_remove,
+	.driver = {
+		.name = DRVNAME,
+	},
+};

drivers/edac/cortex_arm64_l1_l2.c new file +30 -0

+
+		if (!of_match_node(cortex_arm64_edac_of_match, np))
+			continue;
+		if (!of_property_read_bool(np, "edac-enabled"))
+			continue;
+		cpumask_set_cpu(cpu, &compat_mask);
+	}
+
+	if (cpumask_empty(&compat_mask))
+		return 0;
+
+	err = platform_driver_register(&cortex_arm64_edac_driver);
+	if (err)
+		return err;
+
+	pdev = platform_device_register_simple(DRVNAME, -1, NULL, 0);
+	if (IS_ERR(pdev)) {
+		pr_err("failed to register cortex arm64 edac device\n");
+		platform_driver_unregister(&cortex_arm64_edac_driver);
+		return PTR_ERR(pdev);
+	}
+
+	return 0;
+}
+
+device_initcall(cortex_arm64_edac_driver_init);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Sascha Hauer <[email protected]>");
+MODULE_DESCRIPTION("Cortex A72, A57 and A53 L1 and L2 cache EDAC driver");

Signature · 1 line

2.49.0

drivers/edac/cortex_arm64_l1_l2.c line 92

Quoted 10 lines

drivers/edac/cortex_arm64_l1_l2.c new file +10 -0

+		snprintf(msg, MESSAGE_SIZE, "%s %s error(s) on CPU %d",
+			 str, fatal ? "fatal" : "correctable", cpu);
+
+		if (fatal)
+			edac_device_handle_ue(edac_ctl, cpu, 0, msg);
+		else
+			edac_device_handle_ce(edac_ctl, cpu, 0, msg);
+
+		write_sysreg_s(0, SYS_CPUMERRSR_EL1);
+		isb();

I think the register writes and barriers should happen much closer to the register reads, in read_errors(). Looking back at Marc's feedback on v5, I think his most important piece of feedback was to only clear the register when the valid bit is set to avoid accidentally clobbering an error that came in between the register read and write.

By moving the register writes into report_errors() in this v6 series, there's now a much larger window where new errors could occur between the register read and the register write. Those new errors would be silently lost/ignored. Reducing the window to the least number of cycles seems important for accurate reporting.

drivers/edac/cortex_arm64_l1_l2.c line 195

Quoted 9 lines

drivers/edac/cortex_arm64_l1_l2.c new file +9 -0

+static int __init cortex_arm64_edac_driver_init(void)
+{
+	struct device_node *np;
+	int cpu;
+	struct platform_device *pdev;
+	int err;
+
+	for_each_possible_cpu(cpu) {
+		np = of_get_cpu_node(cpu, NULL);

Copilot correctly points out that we don't check np for NULL here. I think of_match_node() handles that fine but we get fairly deep into the call stack before it is caught. Let's go ahead and proactive check the return value.

More importantly, it pointed out that we don't call of_node_put(np) before moving onto the next CPU. This would result in a refcount issue and will need to be fixed.

From: Sascha Hauer <[email protected]>

Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And Correction (EDAC) support on their L1 and L2 caches. This is implemented in implementation defined registers, so usage of this functionality is not safe in virtualized environments or when EL3 already uses these registers. This patch adds a edac-enabled flag which can be explicitly set when EDAC can be used.

Signed-off-by Sascha Hauer <[email protected]>

[vijayb: Added A72 to the commit message]

Signed-off-by Vijay Balakrishna <[email protected]>

---
 Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

Documentation/devicetree/bindings/arm/cpus.yaml +0 -0

index 2e666b2a4dcd..18d649a18552 100644

Quoted 2 lines · Vijay Balakrishna

From: Sascha Hauer <[email protected]>

Quoted 6 lines

Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And Correction (EDAC) support on their L1 and L2 caches. This is implemented in implementation defined registers, so usage of this functionality is not safe in virtualized environments or when EL3 already uses these registers. This patch adds a edac-enabled flag which can be explicitly set when EDAC can be used.

Can't hypervisor tell you that?

Quoted 11 lines · Krzysztof Kozlowski

Quoted 8 lines · Vijay Balakrishna

From: Sascha Hauer <[email protected]>

Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And Correction (EDAC) support on their L1 and L2 caches. This is implemented in implementation defined registers, so usage of this functionality is not safe in virtualized environments or when EL3 already uses these registers. This patch adds a edac-enabled flag which can be explicitly set when EDAC can be used.

Quoted 1 line

Can't hypervisor tell you that?

No, it can't. This is not an architecture feature, and KVM will gladly inject an UNDEF exception if the guest tries to use this.

Which is yet another reason why this whole exercise is futile.

	M.

Signature · 1 line

Without deviation from the norm, progress is not possible.

Quoted 15 lines · Marc Zyngier

Quoted 12 lines · Krzysztof Kozlowski

Quoted 8 lines · Vijay Balakrishna

From: Sascha Hauer <[email protected]>

Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And Correction (EDAC) support on their L1 and L2 caches. This is implemented in implementation defined registers, so usage of this functionality is not safe in virtualized environments or when EL3 already uses these registers. This patch adds a edac-enabled flag which can be explicitly set when EDAC can be used.

Can't hypervisor tell you that?

Quoted 4 lines

No, it can't. This is not an architecture feature, and KVM will gladly inject an UNDEF exception if the guest tries to use this.

Which is yet another reason why this whole exercise is futile.

Hi Marc - could you clarify why this is futile for baremetal or were you just referring to virtualized environments?

Quoted 22 lines · Tyler Hicks (Microsoft)

Quoted 19 lines · Marc Zyngier

Quoted 4 lines · Krzysztof Kozlowski

Quoted 2 lines · Vijay Balakrishna

From: Sascha Hauer <[email protected]>

Quoted 8 lines

Quoted 6 lines

Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And Correction (EDAC) support on their L1 and L2 caches. This is implemented in implementation defined registers, so usage of this functionality is not safe in virtualized environments or when EL3 already uses these registers. This patch adds a edac-enabled flag which can be explicitly set when EDAC can be used.

Can't hypervisor tell you that?

No, it can't. This is not an architecture feature, and KVM will gladly inject an UNDEF exception if the guest tries to use this.

Which is yet another reason why this whole exercise is futile.

Quoted 2 lines

Hi Marc - could you clarify why this is futile for baremetal or were you just referring to virtualized environments?

This is futile in general. This sort of stuff only makes sense if you can take useful action upon detecting an error, such as cache scrubbing. Here, this is just telling you "bang, you're dead", without any other recourse. You are not even sure you'll be able to actually *run* this code. You cannot identify what the blast radius.

We have some other EDAC implementation for arm64 CPUs (XGene, ThunderX), and they are all perfectly useless (I have them in my collection of horrors). I know you are familiar enough with the RAS architecture to appreciate the difference with a contemporary implementation that would actually do the right thing.

Thanks,

	M.

Signature · 1 line

Without deviation from the norm, progress is not possible.

We have some other EDAC implementation for arm64 CPUs (XGene, ThunderX), and they are all perfectly useless (I have them in my collection of horrors).

Quoted 3 lines · Marc Zyngier

We have some other EDAC implementation for arm64 CPUs (XGene, ThunderX), and they are all perfectly useless (I have them in my collection of horrors).

Oh oh, can I remove, can I remove?

My trigger finger is itching to kill some more useless code...