Re: RFC: ACPI code first proposal, _OSC to negotiate use of Memory Section 2 CPER.

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

On Fri, 30 Oct 2026 14:38:02 -0700
Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> wrote:

> Hi All,
> 
> In the discussion of Pierre's patch #1 the question of how a firmware
> could know to send the newer Memory Error Section 2 CPER rather than the
> older record given it currently has no way of knowing what the OS supports.
> 
> Having discussed the problem inside Qualcomm, we can to the same conclusion
> as in Pierre's thread - an _OSC is probably the easiest way to solve this.
> Andrei then drew up a code first ECN proposal.  The text is below, tweaked
> for plain text rendering. Link to proposal #2
> 
> Please draw the attention of others to this. Feedback welcome either on
> this thread, Pierre's thread or directly on the tianocore ticket.

This sounds to be the best approach on my eyes.

> 
> thanks,
> 
> Jonathan
> 
> 
> # Title: OS support for CPER Memory Error Section 2 records
> ## Status: Draft
> ## Document: ACPI Specification Version 6.6
> ## License: SPDX-License-Identifier: CC-BY-4.0
> ## Submitters: Qualcomm
> 
> ## Summary of the change
> Reserves an additional Platform-Wide OSPM Capability bit to negotiate supported CPER
> record format for Memory Error Section (older MES vs newer and richer MES2).
> Memory Error Section 2 records are defined in UEFI 2.11, Section N.2.6 (Appendix N, page
> 2171).
> 
> ## Benefits of the change
> Memory Error Section 2 (MES2) records were added in UEFI Specification 2.11, yet no
> mechanism to negotiate OSPM support for the new record type (Linux kernel support is still
> being added upstream at the moment).
> 
> This change proposes using a new Platform-Wide OSPM Capability to negotiate between
> firmware and the OS for enabling the new format. Until the added _OSC bit is reported by
> OSPM, the older Memory Error Section records will be used. Although this means a platform
> may in practice have to support generating both record formats, this is seen as a better than
> always emitting old- and new- style records which would leave the
> deduplication/reconciliation up to OSPM.
> 
> ## Impact of the change
> Platform firmware should only generate CPER MES2 records if OSPM declared support for
> MES2 records. Otherwise, platform firmware should only generate the older MES records.
> 
> ## Detailed description of the change [normative updates]
> 
> 
> 6.2.11.2 Platform-Wide OSPM Capabilities
> …
> 
> Table 6.13: Platform-Wide _OSC Capabilities DWORD 2
> +---------+--------------------------+--------------------------------------------------+
> | Bits    | Field Name               | Definition                                       |
> +---------+--------------------------+--------------------------------------------------+
> | …       |                          |                                                  |
> +---------+--------------------------+--------------------------------------------------+
> | 22      | Functional Fixed         | The OS sets this bit to indicate support for     |
> |         | Hardware                 | the usage of Functional FixedHardware            |
> |         |                          | (FFixedHW) OperationRegions.                     |
> +---------+--------------------------+--------------------------------------------------+
> | 23      | CPER Memory Error        | The OS sets this bit to indicate support for     |
> |         | Section 2 Support        | MES2 CPER records. If not set, OS support for    |
> |         |                          | older CPER MES records is assumed.               |
> +---------+--------------------------+--------------------------------------------------+
> | 31:24   |                          | Reserved (must be 0)                             |
> +---------+--------------------------+--------------------------------------------------+

My only concern is that it may run out of bits soon if we use those
for each new incompatible types on CPER records.

> 
> [1] https://lore.kernel.org/all/20261019203915.2019037-1-pierre.gondois@arm.com/
> [2] https://github.com/tianocore/edk2/issues/13430
> 
> 



Thanks,
Mauro