From: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
To: Pierre Gondois <pierre.gondois@arm.com>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Tony Luck <tony.luck@intel.com>, Borislav Petkov <bp@alien8.de>,
linux-acpi@vger.kernel.org, Mark Brown <broonie@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-edac@vger.kernel.org, Vikram Sethi <vsethi@nvidia.com>
Cc: Ashok Raj <ashok.raj@oss.qualcomm.com>,
James Morse <james.morse@arm.com>, Len Brown <lenb@kernel.org>,
Shuai Xue <xueshuai@linux.alibaba.com>,
Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>,
Pawel Chmielewski <pawel.chmielewski@intel.com>,
Breno Leitao <leitao@debian.org>,
Ard Biesheuvel <ardb@kernel.org>,
wanghuiqiang@huawei.com
Subject: RFC: ACPI code first proposal, _OSC to negotiate use of Memory Section 2 CPER.
Date: Fri, 30 Oct 2026 14:38:02 -0700 [thread overview]
Message-ID: <20261030143802.0000231d@oss.qualcomm.com> (raw)
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
next reply other threads:[~2026-10-30 21:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 21:38 Jonathan Cameron [this message]
2026-10-31 11:00 ` RFC: ACPI code first proposal, _OSC to negotiate use of Memory Section 2 CPER Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261030143802.0000231d@oss.qualcomm.com \
--to=jonathan.cameron@oss.qualcomm.com \
--cc=ardb@kernel.org \
--cc=ashok.raj@oss.qualcomm.com \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=james.morse@arm.com \
--cc=leitao@debian.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=maciej.wieczor-retman@intel.com \
--cc=mchehab+huawei@kernel.org \
--cc=pawel.chmielewski@intel.com \
--cc=pierre.gondois@arm.com \
--cc=rafael@kernel.org \
--cc=tony.luck@intel.com \
--cc=vsethi@nvidia.com \
--cc=wanghuiqiang@huawei.com \
--cc=xueshuai@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox