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

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

On 10/30/26 16:19, Jonathan Cameron wrote:
> On Fri, 30 Oct 2026 12:51:47 +0100
> Pierre Gondois <pierre.gondois@arm.com> 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@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,
> 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.

Ok thanks,
If you can also also add Mark Brown <broonie@kernel.org>