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

[Ashok Raj]

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.

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? 

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
> 

-- 
/ashok.raj
ashok.raj@xxxxxxxxxxxxxxxx
Qualcomm Inc