mbox series

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

Message ID 20240426-cxl-cper3-v3-0-6ade7dfc849e@intel.com
Headers show
Series efi/cxl-cper: Report CXL CPER events through tracing | expand

Message

Ira Weiny April 26, 2024, 8:02 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.

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
=======

Continue to use my quick hack in debugfs to facilitate easier testing.[1]

[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 v3:
- djbw: drop patch which traces errors if CXL is not loaded
- djbw: Let CXL layer declare work struct.  Leave kfifo management in
  GHES layer
- Link to v2: https://lore.kernel.org/r/20240422-cxl-cper3-v2-0-5cdd378fcd0b@intel.com

---
Ira Weiny (2):
      acpi/ghes: Process CXL Component Events
      cxl/pci: Process CPER events

 drivers/acpi/apei/ghes.c  | 110 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/cxl/pci.c         |  71 +++++++++++++++++++++++++++++-
 include/linux/cxl-event.h |  27 ++++++++++++
 3 files changed, 207 insertions(+), 1 deletion(-)
---
base-commit: e33c4963bf536900f917fb65a687724d5539bc21
change-id: 20240220-cxl-cper3-30e55279f936

Best regards,

Comments

Dan Williams April 26, 2024, 11:50 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]
> 
> 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]
> 
> The use of a kfifo simplifies queue processing by providing lock free
> fifo operations.  cxl_cper_kfifo_get() allows easier management of the
> kfifo between the ghes and cxl modules.
> 
> CXL 3.1 Table 8-127 requires a device to have a queue depth of 1 for
> each of the four event logs.  A combined queue depth of 32 is chosen to
> provide room for 8 entries of each log type.
> 
> Add GHES support to detect CXL CPER records.  Add the ability for the
> CXL sub-system to register a work queue to process the events.
> 
> 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/

Like I mentioned last time, perhaps Dave can reformat these lines on
applying to:

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]

Other than that, this looks good to me:

Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Ira Weiny April 27, 2024, 3:31 a.m. UTC | #2
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/
> 
> Like I mentioned last time, perhaps Dave can reformat these lines on
> applying to:

Yes you did and I rushed these out today.

> 
> 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]
> 
> Other than that, this looks good to me:
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>

Wow!  B4 actually picked these up and added them for me!

I'll respin v4 is like 5 min.

Thanks for the review,
Ira