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

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

[Jonathan Cameron]

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.

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)                             |
+---------+--------------------------+--------------------------------------------------+

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

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

[Mauro Carvalho Chehab]

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