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

[Pierre Gondois <pierre.gondois@arm.com>]

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@kernel.org> wrote:
>>
>>> On Fri, 23 Oct 2026 14:26:21 -0700
>>> Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> wrote:
>>>
>>>> On Thu, 22 Oct 2026 09:07:25 +0200
>>>> Pierre Gondois <pierre.gondois@arm.com> wrote:
>>>>    
>>>>> On 10/20/26 19:10, Jonathan Cameron wrote:
>>>>>> On Mon, 19 Oct 2026 22:38:39 +0200
>>>>>> Pierre Gondois <pierre.gondois@arm.com> 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,

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