[PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Kai-Heng Feng]

Add support for decoding NVIDIA-specific CPER sections delivered via
the APEI GHES vendor record notifier chain. NVIDIA hardware generates
vendor-specific CPER sections containing error signatures and diagnostic
register dumps. This implementation registers a notifier_block with the
GHES vendor record notifier and decodes these sections, printing error
details via dev_info().

The driver binds to ACPI device NVDA2012, present on NVIDIA server
platforms. The NVIDIA CPER section contains a fixed header with error
metadata (signature, error type, severity, socket) followed by
variable-length register address-value pairs for hardware diagnostics.

This work is based on libcper [0].

Example output:
nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
nvidia-ghes NVDA2012:00: signature: CMET-INFO
nvidia-ghes NVDA2012:00: error_type: 0
nvidia-ghes NVDA2012:00: error_instance: 0
nvidia-ghes NVDA2012:00: severity: 3
nvidia-ghes NVDA2012:00: socket: 0
nvidia-ghes NVDA2012:00: number_regs: 32
nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000

[0] https://github.com/openbmc/libcper/commit/683e055061ce
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: Shiju Jose <shiju.jose@huawei.com>
Signed-off-by: Kai-Heng Feng <kaihengf@nvidia.com>
---
v2:
  - Use right headers.
  - Use embedded struct and __counted_by.
  - Drop __packed.
  - Remove unecessary casts. 
  - Use * in sizeof().
  - Use devm_kmalloc() and struct assignment.
  - Use dev_err_probe and new devm helper.

 MAINTAINERS                     |   6 ++
 drivers/acpi/apei/Kconfig       |  14 +++
 drivers/acpi/apei/Makefile      |   1 +
 drivers/acpi/apei/nvidia-ghes.c | 146 ++++++++++++++++++++++++++++++++
 4 files changed, 167 insertions(+)
 create mode 100644 drivers/acpi/apei/nvidia-ghes.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d7241695df96..a9be03fbf1a9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18908,6 +18908,12 @@ S:	Maintained
 F:	drivers/video/fbdev/nvidia/
 F:	drivers/video/fbdev/riva/
 
+NVIDIA GHES VENDOR CPER RECORD HANDLER
+M:	Kai-Heng Feng <kaihengf@nvidia.com>
+L:	linux-acpi@vger.kernel.org
+S:	Maintained
+F:	drivers/acpi/apei/nvidia-ghes.c
+
 NVIDIA VRS RTC DRIVER
 M:	Shubhi Garg <shgarg@nvidia.com>
 L:	linux-tegra@vger.kernel.org
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index 070c07d68dfb..7dc49f14f223 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -74,6 +74,20 @@ config ACPI_APEI_EINJ_CXL
 
 	  If unsure say 'n'
 
+config ACPI_APEI_NVIDIA_GHES
+	tristate "NVIDIA GHES vendor record handler"
+	depends on ACPI_APEI_GHES
+	help
+	  Support for decoding NVIDIA-specific CPER sections delivered via
+	  the APEI GHES vendor record notifier chain. Registers a handler
+	  for the NVIDIA section GUID and logs error signatures, severity,
+	  socket, and diagnostic register address-value pairs.
+
+	  Enable on NVIDIA server platforms (e.g. DGX, HGX) that expose
+	  ACPI device NVDA2012 in their firmware tables.
+
+	  If unsure, say N.
+
 config ACPI_APEI_ERST_DEBUG
 	tristate "APEI Error Record Serialization Table (ERST) Debug Support"
 	depends on ACPI_APEI
diff --git a/drivers/acpi/apei/Makefile b/drivers/acpi/apei/Makefile
index 1a0b85923cd4..4a883f67d698 100644
--- a/drivers/acpi/apei/Makefile
+++ b/drivers/acpi/apei/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_ACPI_APEI_EINJ)	+= einj.o
 einj-y				:= einj-core.o
 einj-$(CONFIG_ACPI_APEI_EINJ_CXL) += einj-cxl.o
 obj-$(CONFIG_ACPI_APEI_ERST_DEBUG) += erst-dbg.o
+obj-$(CONFIG_ACPI_APEI_NVIDIA_GHES) += nvidia-ghes.o
 
 apei-y := apei-base.o hest.o erst.o bert.o
diff --git a/drivers/acpi/apei/nvidia-ghes.c b/drivers/acpi/apei/nvidia-ghes.c
new file mode 100644
index 000000000000..aa2e3a387b49
--- /dev/null
+++ b/drivers/acpi/apei/nvidia-ghes.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * NVIDIA GHES vendor record handler
+ *
+ * Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#include <linux/acpi.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <linux/uuid.h>
+#include <acpi/ghes.h>
+
+static const guid_t nvidia_sec_guid =
+	GUID_INIT(0x6d5244f2, 0x2712, 0x11ec,
+		  0xbe, 0xa7, 0xcb, 0x3f, 0xdb, 0x95, 0xc7, 0x86);
+
+struct cper_sec_nvidia {
+	char	signature[16];
+	__le16	error_type;
+	__le16	error_instance;
+	u8	severity;
+	u8	socket;
+	u8	number_regs;
+	u8	reserved;
+	__le64	instance_base;
+	struct {
+		__le64	addr;
+		__le64	val;
+	} regs[] __counted_by(number_regs);
+};
+
+struct nvidia_ghes_private {
+	struct notifier_block	nb;
+	struct device		*dev;
+};
+
+static void nvidia_ghes_print_error(struct device *dev,
+				    const struct cper_sec_nvidia *nvidia_err,
+				    size_t error_data_length, bool fatal)
+{
+	const char *level = fatal ? KERN_ERR : KERN_INFO;
+	size_t min_size;
+	int i;
+
+	dev_printk(level, dev, "signature: %.16s\n", nvidia_err->signature);
+	dev_printk(level, dev, "error_type: %u\n", le16_to_cpu(nvidia_err->error_type));
+	dev_printk(level, dev, "error_instance: %u\n", le16_to_cpu(nvidia_err->error_instance));
+	dev_printk(level, dev, "severity: %u\n", nvidia_err->severity);
+	dev_printk(level, dev, "socket: %u\n", nvidia_err->socket);
+	dev_printk(level, dev, "number_regs: %u\n", nvidia_err->number_regs);
+	dev_printk(level, dev, "instance_base: 0x%016llx\n",
+		   le64_to_cpu(nvidia_err->instance_base));
+
+	if (nvidia_err->number_regs == 0)
+		return;
+
+	/*
+	 * Validate that all registers fit within error_data_length.
+	 * Each register pair is two little-endian u64s.
+	 */
+	min_size = struct_size(nvidia_err, regs, nvidia_err->number_regs);
+	if (error_data_length < min_size) {
+		dev_err(dev, "Invalid number_regs %u (section size %zu, need %zu)\n",
+			nvidia_err->number_regs, error_data_length, min_size);
+		return;
+	}
+
+	for (i = 0; i < nvidia_err->number_regs; i++)
+		dev_printk(level, dev, "register[%d]: address=0x%016llx value=0x%016llx\n",
+			   i, le64_to_cpu(nvidia_err->regs[i].addr),
+			   le64_to_cpu(nvidia_err->regs[i].val));
+}
+
+static int nvidia_ghes_notify(struct notifier_block *nb,
+			      unsigned long event, void *data)
+{
+	struct acpi_hest_generic_data *gdata = data;
+	struct nvidia_ghes_private *priv;
+	const struct cper_sec_nvidia *nvidia_err;
+	guid_t sec_guid;
+
+	import_guid(&sec_guid, gdata->section_type);
+	if (!guid_equal(&sec_guid, &nvidia_sec_guid))
+		return NOTIFY_DONE;
+
+	priv = container_of(nb, struct nvidia_ghes_private, nb);
+
+	if (acpi_hest_get_error_length(gdata) < sizeof(*nvidia_err)) {
+		dev_err(priv->dev, "Section too small (%d < %zu)\n",
+			acpi_hest_get_error_length(gdata), sizeof(*nvidia_err));
+		return NOTIFY_OK;
+	}
+
+	nvidia_err = acpi_hest_get_payload(gdata);
+
+	if (event >= GHES_SEV_RECOVERABLE)
+		dev_err(priv->dev, "NVIDIA CPER section, error_data_length: %u\n",
+			acpi_hest_get_error_length(gdata));
+	else
+		dev_info(priv->dev, "NVIDIA CPER section, error_data_length: %u\n",
+			 acpi_hest_get_error_length(gdata));
+
+	nvidia_ghes_print_error(priv->dev, nvidia_err, acpi_hest_get_error_length(gdata),
+				event >= GHES_SEV_RECOVERABLE);
+
+	return NOTIFY_OK;
+}
+
+static int nvidia_ghes_probe(struct platform_device *pdev)
+{
+	struct nvidia_ghes_private *priv;
+
+	priv = devm_kmalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	*priv = (struct nvidia_ghes_private) {
+		.nb.notifier_call = nvidia_ghes_notify,
+		.dev = &pdev->dev,
+	};
+
+	return dev_err_probe(&pdev->dev,
+			     devm_ghes_register_vendor_record_notifier(&pdev->dev, &priv->nb),
+			     "Failed to register NVIDIA GHES vendor record notifier\n");
+}
+
+static const struct acpi_device_id nvidia_ghes_acpi_match[] = {
+	{ "NVDA2012" },
+	{ }
+};
+MODULE_DEVICE_TABLE(acpi, nvidia_ghes_acpi_match);
+
+static struct platform_driver nvidia_ghes_driver = {
+	.driver = {
+		.name		= "nvidia-ghes",
+		.acpi_match_table = nvidia_ghes_acpi_match,
+	},
+	.probe	= nvidia_ghes_probe,
+};
+module_platform_driver(nvidia_ghes_driver);
+
+MODULE_AUTHOR("Kai-Heng Feng <kaihengf@nvidia.com>");
+MODULE_DESCRIPTION("NVIDIA GHES vendor CPER record handler");
+MODULE_LICENSE("GPL");
-- 
2.50.1 (Apple Git-155)

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Jonathan Cameron]

On Thu, 19 Mar 2026 19:13:09 +0800
Kai-Heng Feng <kaihengf@nvidia.com> wrote:

> Add support for decoding NVIDIA-specific CPER sections delivered via
> the APEI GHES vendor record notifier chain. NVIDIA hardware generates
> vendor-specific CPER sections containing error signatures and diagnostic
> register dumps. This implementation registers a notifier_block with the
> GHES vendor record notifier and decodes these sections, printing error
> details via dev_info().
> 
> The driver binds to ACPI device NVDA2012, present on NVIDIA server
> platforms. The NVIDIA CPER section contains a fixed header with error
> metadata (signature, error type, severity, socket) followed by
> variable-length register address-value pairs for hardware diagnostics.
> 
> This work is based on libcper [0].
> 
> Example output:
> nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
> nvidia-ghes NVDA2012:00: signature: CMET-INFO
> nvidia-ghes NVDA2012:00: error_type: 0
> nvidia-ghes NVDA2012:00: error_instance: 0
> nvidia-ghes NVDA2012:00: severity: 3
> nvidia-ghes NVDA2012:00: socket: 0
> nvidia-ghes NVDA2012:00: number_regs: 32
> nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
> nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000
> 
> [0] https://github.com/openbmc/libcper/commit/683e055061ce
> Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
> Cc: Shiju Jose <shiju.jose@huawei.com>
> Signed-off-by: Kai-Heng Feng <kaihengf@nvidia.com>
Only significant thing is around use of dev_err_probe().

I'm surprised that didn't give you error messages in the log even on success.

With that fixed (other stuff is all up to you).
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>


>  apei-y := apei-base.o hest.o erst.o bert.o
> diff --git a/drivers/acpi/apei/nvidia-ghes.c b/drivers/acpi/apei/nvidia-ghes.c
> new file mode 100644
> index 000000000000..aa2e3a387b49
> --- /dev/null
> +++ b/drivers/acpi/apei/nvidia-ghes.c

> +static void nvidia_ghes_print_error(struct device *dev,
> +				    const struct cper_sec_nvidia *nvidia_err,
> +				    size_t error_data_length, bool fatal)
> +{
> +	const char *level = fatal ? KERN_ERR : KERN_INFO;
> +	size_t min_size;
> +	int i;
...


> +	 * Validate that all registers fit within error_data_length.
> +	 * Each register pair is two little-endian u64s.
> +	 */
> +	min_size = struct_size(nvidia_err, regs, nvidia_err->number_regs);
> +	if (error_data_length < min_size) {
> +		dev_err(dev, "Invalid number_regs %u (section size %zu, need %zu)\n",
> +			nvidia_err->number_regs, error_data_length, min_size);
> +		return;
> +	}
> +
> +	for (i = 0; i < nvidia_err->number_regs; i++)

Trivial but I'd take advantage of it now being acceptable (in general) to do
	for (int i = 0; i < ....)

> +		dev_printk(level, dev, "register[%d]: address=0x%016llx value=0x%016llx\n",
> +			   i, le64_to_cpu(nvidia_err->regs[i].addr),
> +			   le64_to_cpu(nvidia_err->regs[i].val));
> +}

> +static int nvidia_ghes_probe(struct platform_device *pdev)
> +{
> +	struct nvidia_ghes_private *priv;
> +
> +	priv = devm_kmalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	*priv = (struct nvidia_ghes_private) {
> +		.nb.notifier_call = nvidia_ghes_notify,
> +		.dev = &pdev->dev,
> +	};
> +
> +	return dev_err_probe(&pdev->dev,
> +			     devm_ghes_register_vendor_record_notifier(&pdev->dev, &priv->nb),
That's too not great for readability and dev_err_probe() should only be called on errors
I'm fairly sure it doesn't have special handling for 0 so will call dev_err() or dev_warn()
and print some stuff before saying 'no error'.

	int ret;
	...

	ret = devm_ghes_register_vendor_record_notifier(&pdev->dev, &priv->nb);
	if (ret)
		return dev_err_probe(&pdev->dev,
				      "Failed to register NVIDIA GHES vendor record notifier\n");

	return 0;



> +			     "Failed to register NVIDIA GHES vendor record notifier\n");
> +}
> +
> +static const struct acpi_device_id nvidia_ghes_acpi_match[] = {
> +	{ "NVDA2012" },

London Olympics :)

> +	{ }
> +};
> +MODULE_DEVICE_TABLE(acpi, nvidia_ghes_acpi_match);
> +
> +static struct platform_driver nvidia_ghes_driver = {
> +	.driver = {
> +		.name		= "nvidia-ghes",
> +		.acpi_match_table = nvidia_ghes_acpi_match,
> +	},
> +	.probe	= nvidia_ghes_probe,

I'd just not attempt to align the = 
static struct platform_driver nvidia_ghes_driver = {
	.driver = {
		.name = "nvidia-ghes",
		.acpi_match_table = nvidia_ghes_acpi_match,
	},
	.probe = nvidia_ghes_probe,

There aren't enough of them to make it much of a readability improvement
and doing this often results in unnecessary churn as a driver evolves.
Also it's already broken!

> +};
> +module_platform_driver(nvidia_ghes_driver);
> +
> +MODULE_AUTHOR("Kai-Heng Feng <kaihengf@nvidia.com>");
> +MODULE_DESCRIPTION("NVIDIA GHES vendor CPER record handler");
> +MODULE_LICENSE("GPL");

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Kai-Heng Feng]

On 2026-03-20 10:13, Jonathan Cameron wrote:
> External email: Use caution opening links or attachments
>
>
> On Thu, 19 Mar 2026 19:13:09 +0800
> Kai-Heng Feng <kaihengf@nvidia.com> wrote:
>
> > Add support for decoding NVIDIA-specific CPER sections delivered via
> > the APEI GHES vendor record notifier chain. NVIDIA hardware generates
> > vendor-specific CPER sections containing error signatures and diagnostic
> > register dumps. This implementation registers a notifier_block with the
> > GHES vendor record notifier and decodes these sections, printing error
> > details via dev_info().
> >
> > The driver binds to ACPI device NVDA2012, present on NVIDIA server
> > platforms. The NVIDIA CPER section contains a fixed header with error
> > metadata (signature, error type, severity, socket) followed by
> > variable-length register address-value pairs for hardware diagnostics.
> >
> > This work is based on libcper [0].
> >
> > Example output:
> > nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
> > nvidia-ghes NVDA2012:00: signature: CMET-INFO
> > nvidia-ghes NVDA2012:00: error_type: 0
> > nvidia-ghes NVDA2012:00: error_instance: 0
> > nvidia-ghes NVDA2012:00: severity: 3
> > nvidia-ghes NVDA2012:00: socket: 0
> > nvidia-ghes NVDA2012:00: number_regs: 32
> > nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
> > nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000
> >
> > [0] https://github.com/openbmc/libcper/commit/683e055061ce
> > Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
> > Cc: Shiju Jose <shiju.jose@huawei.com>
> > Signed-off-by: Kai-Heng Feng <kaihengf@nvidia.com>
> Only significant thing is around use of dev_err_probe().
>
> I'm surprised that didn't give you error messages in the log even on success.
>
> With that fixed (other stuff is all up to you).
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
>
>
> >  apei-y := apei-base.o hest.o erst.o bert.o
> > diff --git a/drivers/acpi/apei/nvidia-ghes.c b/drivers/acpi/apei/nvidia-ghes.c
> > new file mode 100644
> > index 000000000000..aa2e3a387b49
> > --- /dev/null
> > +++ b/drivers/acpi/apei/nvidia-ghes.c
>
> > +static void nvidia_ghes_print_error(struct device *dev,
> > +                                 const struct cper_sec_nvidia *nvidia_err,
> > +                                 size_t error_data_length, bool fatal)
> > +{
> > +     const char *level = fatal ? KERN_ERR : KERN_INFO;
> > +     size_t min_size;
> > +     int i;
> ...
>
>
> > +      * Validate that all registers fit within error_data_length.
> > +      * Each register pair is two little-endian u64s.
> > +      */
> > +     min_size = struct_size(nvidia_err, regs, nvidia_err->number_regs);
> > +     if (error_data_length < min_size) {
> > +             dev_err(dev, "Invalid number_regs %u (section size %zu, need %zu)\n",
> > +                     nvidia_err->number_regs, error_data_length, min_size);
> > +             return;
> > +     }
> > +
> > +     for (i = 0; i < nvidia_err->number_regs; i++)
>
> Trivial but I'd take advantage of it now being acceptable (in general) to do
>         for (int i = 0; i < ....)

Didn't know it's acceptable now. Will change.

>
> > +             dev_printk(level, dev, "register[%d]: address=0x%016llx value=0x%016llx\n",
> > +                        i, le64_to_cpu(nvidia_err->regs[i].addr),
> > +                        le64_to_cpu(nvidia_err->regs[i].val));
> > +}
>
> > +static int nvidia_ghes_probe(struct platform_device *pdev)
> > +{
> > +     struct nvidia_ghes_private *priv;
> > +
> > +     priv = devm_kmalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> > +     if (!priv)
> > +             return -ENOMEM;
> > +
> > +     *priv = (struct nvidia_ghes_private) {
> > +             .nb.notifier_call = nvidia_ghes_notify,
> > +             .dev = &pdev->dev,
> > +     };
> > +
> > +     return dev_err_probe(&pdev->dev,
> > +                          devm_ghes_register_vendor_record_notifier(&pdev->dev, &priv->nb),
> That's too not great for readability and dev_err_probe() should only be called on errors
> I'm fairly sure it doesn't have special handling for 0 so will call dev_err() or dev_warn()
> and print some stuff before saying 'no error'.
>
>         int ret;
>         ...
>
>         ret = devm_ghes_register_vendor_record_notifier(&pdev->dev, &priv->nb);
>         if (ret)
>                 return dev_err_probe(&pdev->dev,
>                                       "Failed to register NVIDIA GHES vendor record notifier\n");
>
>         return 0;

OK, will change.

>
>
>
> > +                          "Failed to register NVIDIA GHES vendor record notifier\n");
> > +}
> > +
> > +static const struct acpi_device_id nvidia_ghes_acpi_match[] = {
> > +     { "NVDA2012" },
>
> London Olympics :)

Michael Phelps did great :)

>
> > +     { }
> > +};
> > +MODULE_DEVICE_TABLE(acpi, nvidia_ghes_acpi_match);
> > +
> > +static struct platform_driver nvidia_ghes_driver = {
> > +     .driver = {
> > +             .name           = "nvidia-ghes",
> > +             .acpi_match_table = nvidia_ghes_acpi_match,
> > +     },
> > +     .probe  = nvidia_ghes_probe,
>
> I'd just not attempt to align the =
> static struct platform_driver nvidia_ghes_driver = {
>         .driver = {
>                 .name = "nvidia-ghes",
>                 .acpi_match_table = nvidia_ghes_acpi_match,
>         },
>         .probe = nvidia_ghes_probe,
>
> There aren't enough of them to make it much of a readability improvement
> and doing this often results in unnecessary churn as a driver evolves.
> Also it's already broken!

OK, will change too.

>
> > +};
> > +module_platform_driver(nvidia_ghes_driver);
> > +
> > +MODULE_AUTHOR("Kai-Heng Feng <kaihengf@nvidia.com>");
> > +MODULE_DESCRIPTION("NVIDIA GHES vendor CPER record handler");
> > +MODULE_LICENSE("GPL");
>

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Bjorn Helgaas]

On Thu, Mar 19, 2026 at 07:13:09PM +0800, Kai-Heng Feng wrote:
> Add support for decoding NVIDIA-specific CPER sections delivered via
> the APEI GHES vendor record notifier chain. NVIDIA hardware generates
> vendor-specific CPER sections containing error signatures and diagnostic
> register dumps. This implementation registers a notifier_block with the
> GHES vendor record notifier and decodes these sections, printing error
> details via dev_info().
> 
> The driver binds to ACPI device NVDA2012, present on NVIDIA server
> platforms. The NVIDIA CPER section contains a fixed header with error
> metadata (signature, error type, severity, socket) followed by
> variable-length register address-value pairs for hardware diagnostics.
> 
> This work is based on libcper [0].
> 
> Example output:
> nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
> nvidia-ghes NVDA2012:00: signature: CMET-INFO
> nvidia-ghes NVDA2012:00: error_type: 0
> nvidia-ghes NVDA2012:00: error_instance: 0
> nvidia-ghes NVDA2012:00: severity: 3
> nvidia-ghes NVDA2012:00: socket: 0
> nvidia-ghes NVDA2012:00: number_regs: 32
> nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
> nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000

Is there a convenient way to connect NVDA2012:00 with the actual device?  I
assume this is typically a PCIe device?  How would we relate this with PCIe
errors?

Consider a cover letter.  Some of these comments apply to the series.

Wrap commit logs to fit in 75 columns.  When indented by "git log", all of
these overflow 80 columns by just a few characters.

Possibly reorder so the acpi/apei patches are together.  I don't think the
NVIDIA record handler depends on the PCI patch.

Typical subject line style in drivers/acpi/apei appears to be:

  ACPI: APEI: GHES: Add ...

> +config ACPI_APEI_NVIDIA_GHES
> +	tristate "NVIDIA GHES vendor record handler"
> +	depends on ACPI_APEI_GHES

Maybe s/ACPI_APEI_NVIDIA_GHES/ACPI_APEI_GHES_NVIDIA/ since there will
likely be more, and they'll sort nicely if the vendor is at the end.

> +	help
> +	  Support for decoding NVIDIA-specific CPER sections delivered via
> +	  the APEI GHES vendor record notifier chain. Registers a handler
> +	  for the NVIDIA section GUID and logs error signatures, severity,
> +	  socket, and diagnostic register address-value pairs.
> +
> +	  Enable on NVIDIA server platforms (e.g. DGX, HGX) that expose
> +	  ACPI device NVDA2012 in their firmware tables.

Wrap to fit in 80 columns like the rest of this file.

> +++ b/drivers/acpi/apei/nvidia-ghes.c

Maybe rename to "ghes-nvidia.c" so future decoders for other vendors are
grouped?

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Bjorn Helgaas]

On Fri, Mar 20, 2026 at 09:52:54AM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 19, 2026 at 07:13:09PM +0800, Kai-Heng Feng wrote:
> > Add support for decoding NVIDIA-specific CPER sections delivered via
> ...

> Wrap commit logs to fit in 75 columns.  When indented by "git log", all of
> these overflow 80 columns by just a few characters.

I'm so sorry, I had accidentally resized my window narrower.  These are all
fine; please ignore this and the similar Kconfig comment.

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Kai-Heng Feng]

On 2026-03-20 09:52, Bjorn Helgaas wrote:
> External email: Use caution opening links or attachments
>
>
> On Thu, Mar 19, 2026 at 07:13:09PM +0800, Kai-Heng Feng wrote:
> > Add support for decoding NVIDIA-specific CPER sections delivered via
> > the APEI GHES vendor record notifier chain. NVIDIA hardware generates
> > vendor-specific CPER sections containing error signatures and diagnostic
> > register dumps. This implementation registers a notifier_block with the
> > GHES vendor record notifier and decodes these sections, printing error
> > details via dev_info().
> >
> > The driver binds to ACPI device NVDA2012, present on NVIDIA server
> > platforms. The NVIDIA CPER section contains a fixed header with error
> > metadata (signature, error type, severity, socket) followed by
> > variable-length register address-value pairs for hardware diagnostics.
> >
> > This work is based on libcper [0].
> >
> > Example output:
> > nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
> > nvidia-ghes NVDA2012:00: signature: CMET-INFO
> > nvidia-ghes NVDA2012:00: error_type: 0
> > nvidia-ghes NVDA2012:00: error_instance: 0
> > nvidia-ghes NVDA2012:00: severity: 3
> > nvidia-ghes NVDA2012:00: socket: 0
> > nvidia-ghes NVDA2012:00: number_regs: 32
> > nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
> > nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000
>
> Is there a convenient way to connect NVDA2012:00 with the actual device?  I
> assume this is typically a PCIe device?  How would we relate this with PCIe
> errors?

The CPER report is from ARM RAS firmware and not neccessarily be related
to a PCIe device.

>
> Consider a cover letter.  Some of these comments apply to the series.

Will do in next version.

>
> Wrap commit logs to fit in 75 columns.  When indented by "git log", all of
> these overflow 80 columns by just a few characters.
>
> Possibly reorder so the acpi/apei patches are together.  I don't think the
> NVIDIA record handler depends on the PCI patch.
>
> Typical subject line style in drivers/acpi/apei appears to be:
>
>   ACPI: APEI: GHES: Add ...
>
> > +config ACPI_APEI_NVIDIA_GHES
> > +     tristate "NVIDIA GHES vendor record handler"
> > +     depends on ACPI_APEI_GHES
>
> Maybe s/ACPI_APEI_NVIDIA_GHES/ACPI_APEI_GHES_NVIDIA/ since there will
> likely be more, and they'll sort nicely if the vendor is at the end.

OK, will do.

>
> > +     help
> > +       Support for decoding NVIDIA-specific CPER sections delivered via
> > +       the APEI GHES vendor record notifier chain. Registers a handler
> > +       for the NVIDIA section GUID and logs error signatures, severity,
> > +       socket, and diagnostic register address-value pairs.
> > +
> > +       Enable on NVIDIA server platforms (e.g. DGX, HGX) that expose
> > +       ACPI device NVDA2012 in their firmware tables.
>
> Wrap to fit in 80 columns like the rest of this file.
>
> > +++ b/drivers/acpi/apei/nvidia-ghes.c
>
> Maybe rename to "ghes-nvidia.c" so future decoders for other vendors are
> grouped?

Will do.

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Bjorn Helgaas]

On Tue, Mar 24, 2026 at 05:33:06PM +0800, Kai-Heng Feng wrote:
> On 2026-03-20 09:52, Bjorn Helgaas wrote:
> > On Thu, Mar 19, 2026 at 07:13:09PM +0800, Kai-Heng Feng wrote:
> > > Add support for decoding NVIDIA-specific CPER sections delivered via
> > > the APEI GHES vendor record notifier chain. NVIDIA hardware generates
> > > vendor-specific CPER sections containing error signatures and diagnostic
> > > register dumps. This implementation registers a notifier_block with the
> > > GHES vendor record notifier and decodes these sections, printing error
> > > details via dev_info().
> > >
> > > The driver binds to ACPI device NVDA2012, present on NVIDIA server
> > > platforms. The NVIDIA CPER section contains a fixed header with error
> > > metadata (signature, error type, severity, socket) followed by
> > > variable-length register address-value pairs for hardware diagnostics.
> > >
> > > This work is based on libcper [0].
> > >
> > > Example output:
> > > nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
> > > nvidia-ghes NVDA2012:00: signature: CMET-INFO
> > > nvidia-ghes NVDA2012:00: error_type: 0
> > > nvidia-ghes NVDA2012:00: error_instance: 0
> > > nvidia-ghes NVDA2012:00: severity: 3
> > > nvidia-ghes NVDA2012:00: socket: 0
> > > nvidia-ghes NVDA2012:00: number_regs: 32
> > > nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
> > > nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000
> >
> > Is there a convenient way to connect NVDA2012:00 with the actual
> > device?  I assume this is typically a PCIe device?  How would we
> > relate this with PCIe errors?
> 
> The CPER report is from ARM RAS firmware and not neccessarily be
> related to a PCIe device.

Right, I know CPER is more general than just PCI/PCIe.

But in this case, I think NVDA2012 probably *is* a PCIe device.  How
would we figure out which one?  If we have to manually do an acpidump,
figure out which NVDA2012 is :00, and look for an _ADR or something,
that doesn't really seem convenient for multi-NVDA2012 situations.

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Kai-Heng Feng]

On Wed Mar 25, 2026 at 12:15 AM CST, Bjorn Helgaas wrote:
> External email: Use caution opening links or attachments
>
>
> On Tue, Mar 24, 2026 at 05:33:06PM +0800, Kai-Heng Feng wrote:
>> On 2026-03-20 09:52, Bjorn Helgaas wrote:
>> > On Thu, Mar 19, 2026 at 07:13:09PM +0800, Kai-Heng Feng wrote:
>> > > Add support for decoding NVIDIA-specific CPER sections delivered via
>> > > the APEI GHES vendor record notifier chain. NVIDIA hardware generates
>> > > vendor-specific CPER sections containing error signatures and diagnostic
>> > > register dumps. This implementation registers a notifier_block with the
>> > > GHES vendor record notifier and decodes these sections, printing error
>> > > details via dev_info().
>> > >
>> > > The driver binds to ACPI device NVDA2012, present on NVIDIA server
>> > > platforms. The NVIDIA CPER section contains a fixed header with error
>> > > metadata (signature, error type, severity, socket) followed by
>> > > variable-length register address-value pairs for hardware diagnostics.
>> > >
>> > > This work is based on libcper [0].
>> > >
>> > > Example output:
>> > > nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
>> > > nvidia-ghes NVDA2012:00: signature: CMET-INFO
>> > > nvidia-ghes NVDA2012:00: error_type: 0
>> > > nvidia-ghes NVDA2012:00: error_instance: 0
>> > > nvidia-ghes NVDA2012:00: severity: 3
>> > > nvidia-ghes NVDA2012:00: socket: 0
>> > > nvidia-ghes NVDA2012:00: number_regs: 32
>> > > nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
>> > > nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000
>> >
>> > Is there a convenient way to connect NVDA2012:00 with the actual
>> > device?  I assume this is typically a PCIe device?  How would we
>> > relate this with PCIe errors?
>>
>> The CPER report is from ARM RAS firmware and not neccessarily be
>> related to a PCIe device.
>
> Right, I know CPER is more general than just PCI/PCIe.
>
> But in this case, I think NVDA2012 probably *is* a PCIe device.  How
> would we figure out which one?  If we have to manually do an acpidump,
> figure out which NVDA2012 is :00, and look for an _ADR or something,
> that doesn't really seem convenient for multi-NVDA2012 situations.

It's actually just an ACPI device:
Device (CPER)
{
  Name (_HID, "NVDA2012")  // _HID: Hardware ID
  Name (_UID, 0x00)  // _UID: Unique ID
  Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
}

And that's it.

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Bjorn Helgaas]

On Wed, Mar 25, 2026 at 07:34:50PM +0800, Kai-Heng Feng wrote:
> On Wed Mar 25, 2026 at 12:15 AM CST, Bjorn Helgaas wrote:
> > On Tue, Mar 24, 2026 at 05:33:06PM +0800, Kai-Heng Feng wrote:
> >> On 2026-03-20 09:52, Bjorn Helgaas wrote:
> >> > On Thu, Mar 19, 2026 at 07:13:09PM +0800, Kai-Heng Feng wrote:
> >> > > Add support for decoding NVIDIA-specific CPER sections delivered via
> >> > > the APEI GHES vendor record notifier chain. NVIDIA hardware generates
> >> > > vendor-specific CPER sections containing error signatures and diagnostic
> >> > > register dumps. This implementation registers a notifier_block with the
> >> > > GHES vendor record notifier and decodes these sections, printing error
> >> > > details via dev_info().
> >> > >
> >> > > The driver binds to ACPI device NVDA2012, present on NVIDIA server
> >> > > platforms. The NVIDIA CPER section contains a fixed header with error
> >> > > metadata (signature, error type, severity, socket) followed by
> >> > > variable-length register address-value pairs for hardware diagnostics.
> >> > >
> >> > > This work is based on libcper [0].
> >> > >
> >> > > Example output:
> >> > > nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
> >> > > nvidia-ghes NVDA2012:00: signature: CMET-INFO
> >> > > nvidia-ghes NVDA2012:00: error_type: 0
> >> > > nvidia-ghes NVDA2012:00: error_instance: 0
> >> > > nvidia-ghes NVDA2012:00: severity: 3
> >> > > nvidia-ghes NVDA2012:00: socket: 0
> >> > > nvidia-ghes NVDA2012:00: number_regs: 32
> >> > > nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
> >> > > nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000
> >> >
> >> > Is there a convenient way to connect NVDA2012:00 with the actual
> >> > device?  I assume this is typically a PCIe device?  How would we
> >> > relate this with PCIe errors?
> >>
> >> The CPER report is from ARM RAS firmware and not neccessarily be
> >> related to a PCIe device.
> >
> > Right, I know CPER is more general than just PCI/PCIe.
> >
> > But in this case, I think NVDA2012 probably *is* a PCIe device.  How
> > would we figure out which one?  If we have to manually do an acpidump,
> > figure out which NVDA2012 is :00, and look for an _ADR or something,
> > that doesn't really seem convenient for multi-NVDA2012 situations.
> 
> It's actually just an ACPI device:
> Device (CPER)
> {
>   Name (_HID, "NVDA2012")  // _HID: Hardware ID
>   Name (_UID, 0x00)  // _UID: Unique ID
>   Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
> }
> 
> And that's it.

Weird.  There's nothing for a driver to operate the device with except
_DSM?  The device doesn't need any MMIO resources?  I would expect some
resources described by a _CRS method or some native enumeration protocol
like PCI BARs.

The _UID 0x00 matches the "00" in "NVDA2012:00", but I think that's a
coincidence; I think the "00" in the device name came from the ida_alloc()
in acpi_device_set_name(), not from _UID.

So I still don't know how you would identify the correct part in a system
with multiple NVDA2012 devices.  I do see the "socket" and "instance_base"
in the output.  Maybe that would help, but those seem to be
device-specific, and it seems like we should have a generic mechanism.

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Jonathan Cameron]

On Wed, 25 Mar 2026 10:36:28 -0500
Bjorn Helgaas <helgaas@kernel.org> wrote:

> On Wed, Mar 25, 2026 at 07:34:50PM +0800, Kai-Heng Feng wrote:
> > On Wed Mar 25, 2026 at 12:15 AM CST, Bjorn Helgaas wrote:  
> > > On Tue, Mar 24, 2026 at 05:33:06PM +0800, Kai-Heng Feng wrote:  
> > >> On 2026-03-20 09:52, Bjorn Helgaas wrote:  
> > >> > On Thu, Mar 19, 2026 at 07:13:09PM +0800, Kai-Heng Feng wrote:  
> > >> > > Add support for decoding NVIDIA-specific CPER sections delivered via
> > >> > > the APEI GHES vendor record notifier chain. NVIDIA hardware generates
> > >> > > vendor-specific CPER sections containing error signatures and diagnostic
> > >> > > register dumps. This implementation registers a notifier_block with the
> > >> > > GHES vendor record notifier and decodes these sections, printing error
> > >> > > details via dev_info().
> > >> > >
> > >> > > The driver binds to ACPI device NVDA2012, present on NVIDIA server
> > >> > > platforms. The NVIDIA CPER section contains a fixed header with error
> > >> > > metadata (signature, error type, severity, socket) followed by
> > >> > > variable-length register address-value pairs for hardware diagnostics.
> > >> > >
> > >> > > This work is based on libcper [0].
> > >> > >
> > >> > > Example output:
> > >> > > nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
> > >> > > nvidia-ghes NVDA2012:00: signature: CMET-INFO
> > >> > > nvidia-ghes NVDA2012:00: error_type: 0
> > >> > > nvidia-ghes NVDA2012:00: error_instance: 0
> > >> > > nvidia-ghes NVDA2012:00: severity: 3
> > >> > > nvidia-ghes NVDA2012:00: socket: 0
> > >> > > nvidia-ghes NVDA2012:00: number_regs: 32
> > >> > > nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
> > >> > > nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000  
> > >> >
> > >> > Is there a convenient way to connect NVDA2012:00 with the actual
> > >> > device?  I assume this is typically a PCIe device?  How would we
> > >> > relate this with PCIe errors?  
> > >>
> > >> The CPER report is from ARM RAS firmware and not neccessarily be
> > >> related to a PCIe device.  
> > >
> > > Right, I know CPER is more general than just PCI/PCIe.
> > >
> > > But in this case, I think NVDA2012 probably *is* a PCIe device.  How
> > > would we figure out which one?  If we have to manually do an acpidump,
> > > figure out which NVDA2012 is :00, and look for an _ADR or something,
> > > that doesn't really seem convenient for multi-NVDA2012 situations.  
> > 
> > It's actually just an ACPI device:
> > Device (CPER)
> > {
> >   Name (_HID, "NVDA2012")  // _HID: Hardware ID
> >   Name (_UID, 0x00)  // _UID: Unique ID
> >   Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
> > }
> > 
> > And that's it.  
> 
> Weird.  There's nothing for a driver to operate the device with except
> _DSM?  The device doesn't need any MMIO resources?  I would expect some
> resources described by a _CRS method or some native enumeration protocol
> like PCI BARs.
> 
> The _UID 0x00 matches the "00" in "NVDA2012:00", but I think that's a
> coincidence; I think the "00" in the device name came from the ida_alloc()
> in acpi_device_set_name(), not from _UID.
> 
> So I still don't know how you would identify the correct part in a system
> with multiple NVDA2012 devices.  I do see the "socket" and "instance_base"
> in the output.  Maybe that would help, but those seem to be
> device-specific, and it seems like we should have a generic mechanism.

It's not unique in ACPI terms.  There are a few cases even in the ACPI spec
of IDs that exist just to say some feature is there.

ACPI0017 is an example. Simply says, there be CXL here, go look for the
tables.

Here this device is used to indicate that a platform should be ready to handle
a particular type of error record.  If it happened to expose any other
interfaces, then I agree it would need resources or a _DSM etc.

Basically it's a workaround for the lack of discoverability in APEI /
ACPI error reporting. Could use an _OSC bit for the same job but then
we'd run out of those fast.  Device IDs are near free.

Jonathan


> 

Re: [PATCH v2 3/3] acpi/apei: Add NVIDIA GHES vendor CPER record handler

[Rafael J. Wysocki]

On Wed, Mar 25, 2026 at 6:08 PM Jonathan Cameron
<jonathan.cameron@huawei.com> wrote:
>
> On Wed, 25 Mar 2026 10:36:28 -0500
> Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> > On Wed, Mar 25, 2026 at 07:34:50PM +0800, Kai-Heng Feng wrote:
> > > On Wed Mar 25, 2026 at 12:15 AM CST, Bjorn Helgaas wrote:
> > > > On Tue, Mar 24, 2026 at 05:33:06PM +0800, Kai-Heng Feng wrote:
> > > >> On 2026-03-20 09:52, Bjorn Helgaas wrote:
> > > >> > On Thu, Mar 19, 2026 at 07:13:09PM +0800, Kai-Heng Feng wrote:
> > > >> > > Add support for decoding NVIDIA-specific CPER sections delivered via
> > > >> > > the APEI GHES vendor record notifier chain. NVIDIA hardware generates
> > > >> > > vendor-specific CPER sections containing error signatures and diagnostic
> > > >> > > register dumps. This implementation registers a notifier_block with the
> > > >> > > GHES vendor record notifier and decodes these sections, printing error
> > > >> > > details via dev_info().
> > > >> > >
> > > >> > > The driver binds to ACPI device NVDA2012, present on NVIDIA server
> > > >> > > platforms. The NVIDIA CPER section contains a fixed header with error
> > > >> > > metadata (signature, error type, severity, socket) followed by
> > > >> > > variable-length register address-value pairs for hardware diagnostics.
> > > >> > >
> > > >> > > This work is based on libcper [0].
> > > >> > >
> > > >> > > Example output:
> > > >> > > nvidia-ghes NVDA2012:00: NVIDIA CPER section, error_data_length: 544
> > > >> > > nvidia-ghes NVDA2012:00: signature: CMET-INFO
> > > >> > > nvidia-ghes NVDA2012:00: error_type: 0
> > > >> > > nvidia-ghes NVDA2012:00: error_instance: 0
> > > >> > > nvidia-ghes NVDA2012:00: severity: 3
> > > >> > > nvidia-ghes NVDA2012:00: socket: 0
> > > >> > > nvidia-ghes NVDA2012:00: number_regs: 32
> > > >> > > nvidia-ghes NVDA2012:00: instance_base: 0x0000000000000000
> > > >> > > nvidia-ghes NVDA2012:00: register[0]: address=0x8000000100000000 value=0x0000000100000000
> > > >> >
> > > >> > Is there a convenient way to connect NVDA2012:00 with the actual
> > > >> > device?  I assume this is typically a PCIe device?  How would we
> > > >> > relate this with PCIe errors?
> > > >>
> > > >> The CPER report is from ARM RAS firmware and not neccessarily be
> > > >> related to a PCIe device.
> > > >
> > > > Right, I know CPER is more general than just PCI/PCIe.
> > > >
> > > > But in this case, I think NVDA2012 probably *is* a PCIe device.  How
> > > > would we figure out which one?  If we have to manually do an acpidump,
> > > > figure out which NVDA2012 is :00, and look for an _ADR or something,
> > > > that doesn't really seem convenient for multi-NVDA2012 situations.
> > >
> > > It's actually just an ACPI device:
> > > Device (CPER)
> > > {
> > >   Name (_HID, "NVDA2012")  // _HID: Hardware ID
> > >   Name (_UID, 0x00)  // _UID: Unique ID
> > >   Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
> > > }
> > >
> > > And that's it.
> >
> > Weird.  There's nothing for a driver to operate the device with except
> > _DSM?  The device doesn't need any MMIO resources?  I would expect some
> > resources described by a _CRS method or some native enumeration protocol
> > like PCI BARs.
> >
> > The _UID 0x00 matches the "00" in "NVDA2012:00", but I think that's a
> > coincidence; I think the "00" in the device name came from the ida_alloc()
> > in acpi_device_set_name(), not from _UID.
> >
> > So I still don't know how you would identify the correct part in a system
> > with multiple NVDA2012 devices.  I do see the "socket" and "instance_base"
> > in the output.  Maybe that would help, but those seem to be
> > device-specific, and it seems like we should have a generic mechanism.
>
> It's not unique in ACPI terms.  There are a few cases even in the ACPI spec
> of IDs that exist just to say some feature is there.
>
> ACPI0017 is an example. Simply says, there be CXL here, go look for the
> tables.
>
> Here this device is used to indicate that a platform should be ready to handle
> a particular type of error record.  If it happened to expose any other
> interfaces, then I agree it would need resources or a _DSM etc.
>
> Basically it's a workaround for the lack of discoverability in APEI /
> ACPI error reporting. Could use an _OSC bit for the same job but then
> we'd run out of those fast.  Device IDs are near free.

Well, in principle, an auxiliary device could be registered when a
given ACPI table was present.  It would then trigger a driver load and
the driver would probe against the table in question.