mbox series

[v2,0/3] efi/cxl-cper: Report CXL CPER events through tracing

Message ID 20240422-cxl-cper3-v2-0-5cdd378fcd0b@intel.com
Headers show
Series efi/cxl-cper: Report CXL CPER events through tracing | expand

Message

Ira Weiny April 22, 2024, 10:25 p.m. UTC 
If a device is configured for firmware first CXL event records are not
sent directly to the host, rather they are reported through the EFI
Common Platform Error Records (CPER).  EFI 2.10 Section N.2.14 defines
the CXL CPER to wrap a mostly CXL event payload.

The CXL sub-system uniquely has DPA to HPA translation information.[0]
It also already has event decoding/tracing.  Such translations are very
useful for users to determine which system issues may correspond to
specific hardware events.

The restructuring of the event data structures in 6.8 made sharing the
data between CPER/event logs more efficient.  Now re-wire the sending of
CPER records to the CXL sub-system.

In addition provide a default RAS event should the CXL module not be
loaded.

Series status/background
========================

Smita and Jonathan have been a great help with this series.  Once again
thank you.

Unfortunately, with all the churn surrounding the bug which Dan
Carpenter found the maintainers were force to revert this work.

Testing
=======

A quick hack was added to debugfs patch to facilitate easier testing.[1]

With this it was verified that the bug Dan Carpenter found is fixed.
However, the tp_printk bug Jonathan found remains.  Fortunately,
tp_printk is not widely used so it is anticipated this will not be an
issue.

[0]
Link: https://lore.kernel.org/all/cover.1711598777.git.alison.schofield@intel.com/
[1]
Link: https://github.com/weiny2/linux-kernel/commit/9b1f33314e8488506dbad63dc1c896386d4803d6

Signed-off-by: Ira Weiny <ira.weiny@intel.com>
---
Changes in v2:
- iweiny: address comments from V1 (noted in the patches themselves)
- iweiny: drop header file clean up patch (only needed for my debugfs test)
- Link to v1: https://lore.kernel.org/r/20240228-cxl-cper3-v1-0-6aa3f1343c6c@intel.com

---
Ira Weiny (3):
      acpi/ghes: Process CXL Component Events
      cxl/pci: Process CPER events
      ras/events: Trace CXL CPER events without CXL stack

 drivers/acpi/apei/ghes.c  | 128 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/cxl/pci.c         |  61 +++++++++++++++++++++-
 include/linux/cxl-event.h |  18 +++++++
 include/ras/ras_event.h   |  51 ++++++++++++++++++
 4 files changed, 257 insertions(+), 1 deletion(-)
---
base-commit: 4d2008430ce87061c9cefd4f83daf2d5bb323a96
change-id: 20240220-cxl-cper3-30e55279f936

Best regards,

Comments

Dan Williams April 22, 2024, 11:54 p.m. UTC | #1 
Ira Weiny wrote:
> BIOS can configure memory devices as firmware first.  This will send CXL
> events to the firmware instead of the OS.  The firmware can then inform
> the OS of these events via UEFI.
> 
> UEFI v2.10 section N.2.14 defines a Common Platform Error Record (CPER)
> format for CXL Component Events.  The format is mostly the same as the
> CXL Common Event Record Format.  The difference lies in the use of a
> GUID as the CPER Section Type which matches the UUID defined in CXL 3.1
> Table 8-43.
> 
> Currently a configuration such as this will trace a non standard event
> in the log omitting useful details of the event.  In addition the CXL
> sub-system contains additional region and HPA information useful to the
> user.[0]
> 
> Add GHES support to detect CXL CPER records.  Add the ability for the
> CXL sub-system to register a callback to receive the events.
> 
> The CXL code is required to be called from process context as it needs
> to take a device lock.  The GHES code may be in interrupt context.  This
> complicated the use of a callback.  Dan Williams suggested the use of
> work items as an atomic way of switching between the callback execution
> and a default handler.[1]
> 
> This patch adds back the functionality which was removed to fix the
> report by Dan Carpenter[2].
> 
> [0]
> Link: https://lore.kernel.org/all/cover.1711598777.git.alison.schofield@intel.com/
> [1]
> Link: https://lore.kernel.org/all/65d111eb87115_6c745294ac@dwillia2-xfh.jf.intel.com.notmuch/
> [2]
> Link: https://lore.kernel.org/all/b963c490-2c13-4b79-bbe7-34c6568423c7@moroto.mountain/

Minor, but this can be reformatted a bit cleaner:

Link: http://lore.kernel.org/r/cover.1711598777.git.alison.schofield@intel.com [0]
Link: http://lore.kernel.org/r/65d111eb87115_6c745294ac@dwillia2-xfh.jf.intel.com.notmuch [1]
Link: http://lore.kernel.org/r/b963c490-2c13-4b79-bbe7-34c6568423c7@moroto.mountain [2]

> 
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> 
> ---
> Changes:
> [iweiny: clarify commit message]
> [djbw: remove local wt]
> ---
>  drivers/acpi/apei/ghes.c  | 124 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/cxl-event.h |  18 +++++++
>  2 files changed, 142 insertions(+)
> 
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 512067cac170..cdcfdf6ebe81 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -26,6 +26,8 @@
>  #include <linux/interrupt.h>
>  #include <linux/timer.h>
>  #include <linux/cper.h>
> +#include <linux/cleanup.h>
> +#include <linux/cxl-event.h>
>  #include <linux/platform_device.h>
>  #include <linux/mutex.h>
>  #include <linux/ratelimit.h>
> @@ -33,6 +35,7 @@
>  #include <linux/irq_work.h>
>  #include <linux/llist.h>
>  #include <linux/genalloc.h>
> +#include <linux/kfifo.h>
>  #include <linux/pci.h>
>  #include <linux/pfn.h>
>  #include <linux/aer.h>
> @@ -673,6 +676,112 @@ static void ghes_defer_non_standard_event(struct acpi_hest_generic_data *gdata,
>  	schedule_work(&entry->work);
>  }
>  
> +/* CXL Event record UUIDs are formated as GUIDs and reported in section type */
> +
> +/*
> + * General Media Event Record
> + * CXL rev 3.0 Section 8.2.9.2.1.1; Table 8-43
> + */
> +#define CPER_SEC_CXL_GEN_MEDIA_GUID					\
> +	GUID_INIT(0xfbcd0a77, 0xc260, 0x417f,				\
> +		  0x85, 0xa9, 0x08, 0x8b, 0x16, 0x21, 0xeb, 0xa6)
> +
> +/*
> + * DRAM Event Record
> + * CXL rev 3.0 section 8.2.9.2.1.2; Table 8-44
> + */
> +#define CPER_SEC_CXL_DRAM_GUID						\
> +	GUID_INIT(0x601dcbb3, 0x9c06, 0x4eab,				\
> +		  0xb8, 0xaf, 0x4e, 0x9b, 0xfb, 0x5c, 0x96, 0x24)
> +
> +/*
> + * Memory Module Event Record
> + * CXL rev 3.0 section 8.2.9.2.1.3; Table 8-45
> + */
> +#define CPER_SEC_CXL_MEM_MODULE_GUID					\
> +	GUID_INIT(0xfe927475, 0xdd59, 0x4339,				\
> +		  0xa5, 0x86, 0x79, 0xba, 0xb1, 0x13, 0xb7, 0x74)
> +
> +struct cxl_cper_work_data {
> +	enum cxl_event_type event_type;
> +	struct cxl_cper_event_rec rec;
> +};
> +
> +DEFINE_KFIFO(cxl_cper_fifo, struct cxl_cper_work_data, 32);

Any comment on where that "32" comes from?

> +static DEFINE_SPINLOCK(cxl_cper_work_lock);

Needs a comment on what it is specifically protecting.

> +static cxl_cper_callback cper_callback;
> +static void cxl_cper_cb_fn(struct work_struct *work)
> +{
> +	struct cxl_cper_work_data wd;
> +
> +	while (kfifo_get(&cxl_cper_fifo, &wd))
> +		cper_callback(wd.event_type, &wd.rec);
> +}
> +static DECLARE_WORK(cxl_cb_work, cxl_cper_cb_fn);
> +struct work_struct *cxl_cper_work = NULL;

Initializing global data to NULL is redundant, however this feels like
one too many dynamic things registered.

cxl_cper_work and cper_callback are dynamic, but from the GHES
perspective all it cares about is checking if work is registered and if
so put the data in the kfifo and trigger that work func.

It need not care about what happens after the work is queued. So, lets
just have the CXL driver register its own cxl_cper_work instance and
skip defining one locally here. Export cxl_cper_fifo for the driver to
optionally reference.

> +
> +static void cxl_cper_post_event(enum cxl_event_type event_type,
> +				struct cxl_cper_event_rec *rec)
> +{
> +	struct cxl_cper_work_data wd;
> +
> +	if (rec->hdr.length <= sizeof(rec->hdr) ||
> +	    rec->hdr.length > sizeof(*rec)) {
> +		pr_err(FW_WARN "CXL CPER Invalid section length (%u)\n",
> +		       rec->hdr.length);
> +		return;
> +	}
> +
> +	if (!(rec->hdr.validation_bits & CPER_CXL_COMP_EVENT_LOG_VALID)) {
> +		pr_err(FW_WARN "CXL CPER invalid event\n");
> +		return;
> +	}
> +
> +	guard(spinlock_irqsave)(&cxl_cper_work_lock);
> +
> +	if (!cxl_cper_work)
> +		return;
> +
> +	wd.event_type = event_type;
> +	memcpy(&wd.rec, rec, sizeof(wd.rec));
> +
> +	if (!kfifo_put(&cxl_cper_fifo, wd)) {
> +		pr_err_ratelimited("CXL CPER kfifo overflow\n");
> +		return;
> +	}
> +
> +	schedule_work(cxl_cper_work);
> +}
> +
> +int cxl_cper_register_callback(cxl_cper_callback callback)
> +{
> +	if (cper_callback)
> +		return -EINVAL;
> +
> +	guard(spinlock)(&cxl_cper_work_lock);
> +	cper_callback = callback;
> +	cxl_cper_work = &cxl_cb_work;

Per above this would just become cxl_cper_register_work(), and then the
lock makes more sense as a cxl_cper_register_lock.


> +	return 0;
> +}
> +EXPORT_SYMBOL_NS_GPL(cxl_cper_register_callback, CXL);
> +
> +int cxl_cper_unregister_callback(cxl_cper_callback callback)
> +{
> +	if (callback != cper_callback)
> +		return -EINVAL;
> +
> +	/* Avoid guard() because cancel_work_sync() can sleep */
> +	spin_lock(&cxl_cper_work_lock);
> +	cxl_cper_work = NULL;
> +	spin_unlock(&cxl_cper_work_lock);
> +
> +	cancel_work_sync(&cxl_cb_work);

Also per above, moving the responsibility of cancel_work_sync() to
caller also brings guard() back in play here.
Dan Williams April 23, 2024, 12:16 a.m. UTC | #2 
Ira Weiny wrote:
> If CXL is solely managed by firmware (including HDM configuration and
> event processing via firmware first) it is possible to run the system
> without the CXL software loaded.  In this case no CXL callback will be
> loaded and CXL CPER errors will not be processed at all.
> 
> In this case memory device and region (HPA) information is missing but
> omitting the error completely is not friendly.  Some device information
> is available the event.
> 
> Trace CXL CPER events if the CXL stack is not loaded.  A balance was
> chosen to decode only the CPER header as this configuration is likely
> rare.

I think the justification for this is weak and it pollutes the user ABI.
What environment cares about CXL RAS without the CXL driver? If such a
use case ever pops up it is trivial to revive this otherwise saves
carrying this and all the minor maintenance overhead it causes.
Ira Weiny April 23, 2024, 3:47 a.m. UTC | #3 
Dan Williams wrote:
> Ira Weiny wrote:

[snip]

> > 
> > [0]
> > Link: https://lore.kernel.org/all/cover.1711598777.git.alison.schofield@intel.com/
> > [1]
> > Link: https://lore.kernel.org/all/65d111eb87115_6c745294ac@dwillia2-xfh.jf.intel.com.notmuch/
> > [2]
> > Link: https://lore.kernel.org/all/b963c490-2c13-4b79-bbe7-34c6568423c7@moroto.mountain/
> 
> Minor, but this can be reformatted a bit cleaner:
> 
> Link: http://lore.kernel.org/r/cover.1711598777.git.alison.schofield@intel.com [0]
> Link: http://lore.kernel.org/r/65d111eb87115_6c745294ac@dwillia2-xfh.jf.intel.com.notmuch [1]
> Link: http://lore.kernel.org/r/b963c490-2c13-4b79-bbe7-34c6568423c7@moroto.mountain [2]
> 

Sure.


[snip]

> > +/*
> > + * Memory Module Event Record
> > + * CXL rev 3.0 section 8.2.9.2.1.3; Table 8-45
> > + */
> > +#define CPER_SEC_CXL_MEM_MODULE_GUID					\
> > +	GUID_INIT(0xfe927475, 0xdd59, 0x4339,				\
> > +		  0xa5, 0x86, 0x79, 0xba, 0xb1, 0x13, 0xb7, 0x74)
> > +
> > +struct cxl_cper_work_data {
> > +	enum cxl_event_type event_type;
> > +	struct cxl_cper_event_rec rec;
> > +};
> > +
> > +DEFINE_KFIFO(cxl_cper_fifo, struct cxl_cper_work_data, 32);
> 
> Any comment on where that "32" comes from?

If anyone has any better queue depth I'm open.  It is just a guess.

> 
> > +static DEFINE_SPINLOCK(cxl_cper_work_lock);
> 
> Needs a comment on what it is specifically protecting.

Ok.

> 
> > +static cxl_cper_callback cper_callback;
> > +static void cxl_cper_cb_fn(struct work_struct *work)
> > +{
> > +	struct cxl_cper_work_data wd;
> > +
> > +	while (kfifo_get(&cxl_cper_fifo, &wd))
> > +		cper_callback(wd.event_type, &wd.rec);
> > +}
> > +static DECLARE_WORK(cxl_cb_work, cxl_cper_cb_fn);
> > +struct work_struct *cxl_cper_work = NULL;
> 
> Initializing global data to NULL is redundant, however this feels like
> one too many dynamic things registered.
> 
> cxl_cper_work and cper_callback are dynamic, but from the GHES
> perspective all it cares about is checking if work is registered and if
> so put the data in the kfifo and trigger that work func.
> 
> It need not care about what happens after the work is queued. So, lets
> just have the CXL driver register its own cxl_cper_work instance and
> skip defining one locally here. Export cxl_cper_fifo for the driver to
> optionally reference.

Ok I thought we had decided not to do that.  If I recall exporting the
fifo had some difficulties but it may have been my unfamiliarity with it.

Ira

[snip]
Ira Weiny April 23, 2024, 4:10 a.m. UTC | #4 
Dan Williams wrote:
> Ira Weiny wrote:
> > If CXL is solely managed by firmware (including HDM configuration and
> > event processing via firmware first) it is possible to run the system
> > without the CXL software loaded.  In this case no CXL callback will be
> > loaded and CXL CPER errors will not be processed at all.
> > 
> > In this case memory device and region (HPA) information is missing but
> > omitting the error completely is not friendly.  Some device information
> > is available the event.
> > 
> > Trace CXL CPER events if the CXL stack is not loaded.  A balance was
> > chosen to decode only the CPER header as this configuration is likely
> > rare.
> 
> I think the justification for this is weak and it pollutes the user ABI.

Do you want me to drop this patch or slim the tracepoint down even
further?

Looking at this again I feel like 

	54ce1927eb78 ("cxl/cper: Fix errant CPER prints for CXL events") 

Was a mistake.  PCI AER errors are both printed in
cper_estatus_print_section() and again printed/traced in pci_print_aer()

Why should CXL be any different?

Ira
Ira Weiny April 23, 2024, 4:16 a.m. UTC | #5 
Ira Weiny wrote:
> Dan Williams wrote:
> > Ira Weiny wrote:
> 

[snip]

> > 
> > > +static cxl_cper_callback cper_callback;
> > > +static void cxl_cper_cb_fn(struct work_struct *work)
> > > +{
> > > +	struct cxl_cper_work_data wd;
> > > +
> > > +	while (kfifo_get(&cxl_cper_fifo, &wd))
> > > +		cper_callback(wd.event_type, &wd.rec);
> > > +}
> > > +static DECLARE_WORK(cxl_cb_work, cxl_cper_cb_fn);
> > > +struct work_struct *cxl_cper_work = NULL;
> > 
> > Initializing global data to NULL is redundant, however this feels like
> > one too many dynamic things registered.
> > 
> > cxl_cper_work and cper_callback are dynamic, but from the GHES
> > perspective all it cares about is checking if work is registered and if
> > so put the data in the kfifo and trigger that work func.
> > 
> > It need not care about what happens after the work is queued. So, lets
> > just have the CXL driver register its own cxl_cper_work instance and
> > skip defining one locally here. Export cxl_cper_fifo for the driver to
> > optionally reference.
> 
> Ok I thought we had decided not to do that.  If I recall exporting the
> fifo had some difficulties but it may have been my unfamiliarity with it.

Looking more closely I see that AER does something similar but it uses
constructs which I thought we should avoid.  For example all of
ghes_handle_aer is predicated on CONFIG_ACPI_APEI_PCIEAER.[0]

What I have is a bit complicated, with the extra pointer.  Keeping the
kfifo within the ghes module is much easier to follow IMO.

Let me know if you really want me to pursue this separation but my late
night gut feeling is this is going to be more trouble than it is worth to
keep the separation amongst the modules.

Ira

[0]
static void ghes_handle_aer(struct acpi_hest_generic_data *gdata)
{                                        
#ifdef CONFIG_ACPI_APEI_PCIEAER
	...
#endif
}