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

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

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

[1] Not sure about the outcome of the above.

>>>>   
>>>>> 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>
>>
> https://lore.kernel.org/linux-acpi/20261030143802.0000231d@oss.qualcomm.com/
>
> I started a new thread so it wasn't too buried.

Thanks !

Just to be sure, the _OSC discussion should not prevent this patchset
to proceed right ? I think there is only [1] which I m not sure about the
outcome otherwise,

Regards,

Pierre