RE: [PATCH 1/3] efi/cper, cxl: Decode CXL Component Events General Media Event Record

[Dan Williams]

Smita Koralahalli wrote:
> Add support for decoding CXL Component Events General Media Event Record
> as defined in CXL rev 3.0 section 8.2.9.2.1.1.
> 
> All the event records as defined in Event Record Identifier field of the
> Common Event Record Format in CXL rev 3.0 section 8.2.9.2.1 follow the
> CPER format for representing the hardware errors if reported by a
> platform.
> 
> According to the CPER format, each event record including the General
> Media is logged as a CXL Component Event as defined in UEFI 2.10
> Section N.2.14 and is identified by a UUID as defined by Event Record
> Identifier field in Common Event Record Format of CXL rev 3.0 section
> 8.2.9.2.1. CXL Component Event Log field in Component Events Section
> corresponds to the component/event specified by the section type UUID.
> 
> Add support for decoding CXL Component Events as defined in UEFI 2.10
> Section N.2.14 and decoding Common Event Record as defined in CXL rev 3.0
> section 8.2.9.2.1.

So I think this is missing the rationale for the code duplication.

Specifically, who is the consumer of this parsing relative to who is the
consumer of the event records emitted by the CXL subsystem. Given the
CXL subsystem event parsing already exists, and unlike this
implementation can support DPA-to-HPA translation, why should Linux
carry 2 emitters for what is effectively the same data?

What I would like to see is the CPER code post these record payloads on
a notifier chain for the CXL subsystem to parse, annotate with extra CXL
subsystem information, and emit from one control point.

Otherwise if folks would like to see this printk() version of the error
records then they also need to answer why the CXL subsystem should not
also emit decoder error logs to printk?