Re: [PATCH v2 0/6] CPER: Add Memory Error Section 2 support

[Jonathan Cameron]

On Fri, 30 Oct 2026 12:51:47 +0100
Pierre Gondois <pierre.gondois@xxxxxxx> wrote:

> On 10/25/26 00:05, Ashok Raj wrote:
> > On Fri, Oct 23, 2026 at 05:04:05PM -0700, Jonathan Cameron wrote:  
> >> On Sat, 24 Oct 2026 00:40:33 +0200
> >> Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote:
> >>  
> >>> On Fri, 23 Oct 2026 14:26:21 -0700
> >>> Jonathan Cameron <jonathan.cameron@xxxxxxxxxxxxxxxx> wrote:
> >>>  
> >>>> On Thu, 22 Oct 2026 09:07:25 +0200
> >>>> Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
> >>>>      
> >>>>> On 10/20/26 19:10, Jonathan Cameron wrote:  
> >>>>>> On Mon, 19 Oct 2026 22:38:39 +0200
> >>>>>> Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
> >>>>>>         
> >>>>>>> The support is mostly duplicated from Memory Error Section handling.
> >>>>>>> Other than differences coming from the content of  Memory Error
> >>>>>>> Section 1 and 2, differences in the support are:
> >>>>>>>
> >>>>>>> - v2 do not rely on a compact "struct cper_mem_err_compact" struct.
> >>>>>>> This structure was used to support older versions of the Memory
> >>>>>>> Error Section (1). This is not needed for the new structure.
> >>>>>>>
> >>>>>>> - The compact version is also used by the tracing framework.
> >>>>>>> To avoid relying and propagating a non-standard record format,
> >>>>>>> through trace event (cf. extlog_mem event) the new trace event
> >>>>>>> prints each field individually.
> >>>>>>>
> >>>>>>> The last patch of the serie was only build-tested due to the
> >>>>>>> absence of relevant hardware. apei_mce_report_mem_error() and
> >>>>>>> arch_apei_report_mem_error() implementations were also removed since
> >>>>>>> last version.
> >>>>>>>
> >>>>>>> It will also require a proper handling from the rasdaemon. Applying
> >>>>>>> this last patch without rasdaemon support will silent the reports of
> >>>>>>> Memory Error Section 2 error, cf. ras_userspace_consumers() check.  
> >>>>>> Hi Pierre,
> >>>>>>
> >>>>>> I'd slow down a bit.  We are mid merge window and convention is normally
> >>>>>> one version a week or so anyway.  Better to gather up feedback from
> >>>>>> a number of folk and spin only one revision to cover it all.
> >>>>>>         
> >>>>> Hello Jonathan,
> >>>>>
> >>>>> Ok sure, as the v1 was reviewed quickly I thought there was a chance
> >>>>> of having the serie accepted quickly aswell. I ll wait a bit more.
> >>>>>
> >>>>> Thanks for the review,
> >>>>>
> >>>>> Pierre
> >>>>>        
> >>>> A general question that came up in a related thread with one of
> >>>> our RAS architects. How does firmware decide what to send?  As far as
> >>>> I can tell firwmare has no way to know whether the OS understands the CPER
> >>>> Memory Section 2.
> >>>>
> >>>> So options that come to mind.
> >>>> 1. Firmware must send a CPER with both Memory Section and Memory Section 2.  
> >>> Please don't do this: this would require either Kernespace or userspace to
> >>> discard one of the reports, only if the other one is there, which can be
> >>> tricky. Could be done more easily at userspace, but only if some database
> >>> support is enabled, but, at least on rasdaemon, this is an optional module.  
> >> Good. That confirms my view that is horrible.  
> > Hi Jonathan,
> >
> > I agree that an _OSC capability is the right long-term solution.
> >
> > Firmware should select one native CPER format based on OS support, rather
> > than emit both Section 1 and Section 2 and leave deduplication to the OS
> > or userspace.
> >
> > For a Section 2-capable kernel, we may still avoid a second GHES notifier
> > chain: preserve the existing struct cper_sec_mem_err * contract and give
> > it a lossy Section 1 projection of a Section 2 record. The conversion must
> > translate validation bits and clear validity for values that cannot be
> > represented, rather than truncate them.  
> 
> I understand we might want to emit a new extlog_mem2_event and a lossy
> extlog_mem_event for legacy userspace, but I'm not sure to follow how
> you want to do it.
> 
> Do you suggest that we only need one notifier (ghes_report_mem_chain)
> and that we should not add ghes_report_mem2_chain ? This would mean
> that the .notifier_call (= ghes_edac_report_mem_error) should handle
> both cper_sec_mem_err/cper_sec_mem_err2 struct.
> 
> Another solution would be to keep the ghes_report_mem2_chain,
> which would be responsible of creating the lossy v1 struct and
> triggering the original ghes_report_mem_chain.
> 
> > That preserves legacy EDAC consumers, but cannot carry all Section 2 data.
> > Updated userspace needs the native Section 2 payload through a
> > full-fidelity path, such as the existing GUID-tagged raw CPER event.
> >
> > This does mean an updated userspace listener may receive both the legacy
> > EDAC summary and the raw Section 2 record for the same firmware error.
> > They are two kernel views, not two firmware reports. We should therefore
> > add a shared GHES record/section ID to both events, so userspace can
> > correlate them reliably; address and timestamp are not sufficient.
> >
> > So _OSC solves firmware selection for old versus new kernels, while a
> > Section 1 projection plus the raw payload handles legacy versus updated
> > consumers on a new kernel.
> >
> > Thoughts?  
> 
> This will put more burden on the firmware, but this seems the right
> thing to do. I ll share the thread with the group working more closely
> on the architecture aswell,

We have will have a code first proposal for the _OSC part shortly. Just going
through internal review.  I'll make sure you + others here are on the +CC.

J

> 
> Regards,
> 
> Pierre
> 
> 
> > Thanks,
> > Ashok  
> >>>> 2. For whatever other reason a platform knows it doesn't work with old kernel
> >>>>     so can assume support in kernel and hopefully userspace got updated too.
> >>>>
> >>>> 3. We propose some additional discoverability (quickly - code first) to ACPI
> >>>>     so that it can be a negotiated contract between OS and firmware.
> >>>>     Until the OS confirms it understands Memory Section 2, firmware has to send
> >>>>     the older one (or risk the record not being understood).  After that
> >>>>     negotiation it can do what it likes - probably send the Memory Section 2 form.
> >>>>
> >>>> Option 1 and 2 are ugly at best.
> >>>>
> >>>> Obvious path to me for option 3 is an _OSC like the one for generic initiators
> >>>> that we discovered a need for whilst implementing that years ago.
> >>>>
> >>>> Anyhow have a better idea?  The above doesn't solve the end to end problem as
> >>>> maybe userspace still has no idea what this new tracepoint is, but at least gets
> >>>> us past hop 1 (so through the kernel).
> >>>>
> >>>> If we conclude _OSC plan works I'll draft a code first proposal.
> >>>>
> >>>> Jonathan  
> >> On another note, Pierre, any plans to actually enable a path to the tracepoints
> >> on arm64?  Today they only emerge from acpi_extlog which is x86 only.
> >>
> >> We definitely want the richer data for PFA and obviously for userspace nice
> >> to share tracepoints with extlog.
> >>
> >> Jonathan
> >>
> >>  
> >>> Regards,
> >>> Mauro