[Draft] Add RMEM ACPI reporting proposal

[Youngjun Lee (chapsiru)]

Description

This draft PR adds a proposed Reserved-Memory Reporting (RMEM) ACPI interface for discussion.

Firmware may reserve physical memory for security services, firmware runtime use, shared communication buffers, graphics, NPUs, crash handling, and other platform functions. Operating systems generally expose only the aggregate hardware-reserved amount or efi descriptor, which makes it difficult to identify the purpose and owner of individual reservations.

This change introduces:

• A Revision 1 RMEM ACPI table containing the base address, size, category, and diagnostic label for each reserved-memory range.
• A versioned GUID HOB for reservations discovered before DXE.
• A DXE registration protocol for dynamic or late-discovered reservations.
• A common DXE publisher that:
  • Imports RMEM HOB records.
  • Accepts protocol registrations until ReadyToBoot.
  • Validates ranges, categories, labels, duplicates, and overlaps.
  • Constructs and checksums one RMEM ACPI table.
  • Installs the table through EFI_ACPI_TABLE_PROTOCOL.
• Package declarations for the RMEM HOB and registration protocol GUIDs.

This is a discussion proposal and is not ready to merge. Feedback is requested on:

• The ACPI table layout, category taxonomy, and revision policy.
• ACPI signature allocation and the standardization path.
• Package ownership while RMEM is not yet an approved ACPI standard.
• Whether pre-DXE HOB reporting, DXE protocol reporting, or both should be supported.
• The testing and platform-validation requirements.
• etc.

For details on how to complete these options and their meaning refer to CONTRIBUTING.md.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

The change adds new opt-in functionality and does not modify an existing interface. It has security and privacy implications because it exposes reserved physical-memory addresses, sizes, categories, and labels to operating-system consumers. The table is diagnostic only and does not grant access to the reported memory.

Public interface and data-format documentation is included in the new headers.

How This Was Tested

The following Mu non-compiler CI checks passed for MdePkg and MdeModulePkg:

• GUID uniqueness
• Package dependency validation
• DSC completeness
• License validation
• Character encoding and line-ending checks
• Uncrustify and other static formatting checks
• Editor diagnostics
• Patch whitespace validation

The checks were run with:

stuart_ci_build.exe `
  -c CISettings.py `
  -p MdeModulePkg,MdePkg `
  -a X64 `
  -t NOOPT `
  CompilerPlugin=skip `
  HostUnitTestCompilerPlugin=skip

[mu-automation]

❌ QEMU Validation Failed

Source Dependencies

Repository	Commit
mu_basecore	dd11122
mu_tiano_platforms	af5ef34

Results

Platform	Target	Build	Boot	Overall Boot Time	Build Logs	Boot Logs
Q35	DEBUG	❌ failure	⏩ skipped	N/A	Build Logs	N/A
ArmVirt	DEBUG	✅ success	✅ success	0m 14s	Build Logs	Boot Logs

Workflow run: https://github.com/microsoft/mu_basecore/actions/runs/33115063070

This comment was automatically generated by the Mu QEMU PR Validation workflow.

[Codecov Comments Bot (codecov-commenter)]

Codecov Report

❌ Patch coverage is 81.53846% with 24 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (release/202511@f44f77a). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...ModulePkg/Universal/Acpi/RmemAcpiDxe/RmemAcpiDxe.c	81.53%	19 Missing and 5 partials ⚠️

Additional details and impacted files

@@                Coverage Diff                @@
##             release/202511    #1893   +/-   ##
=================================================
  Coverage                  ?    2.25%           
=================================================
  Files                     ?     1671           
  Lines                     ?   427238           
  Branches                  ?     5126           
=================================================
  Hits                      ?     9635           
  Misses                    ?   417514           
  Partials                  ?       89           

Flag	Coverage Δ
FmpDevicePkg	9.53% <ø> (?)
MdeModulePkg	1.70% <81.53%> (?)
MdePkg	5.44% <ø> (?)
NetworkPkg	0.55% <ø> (?)
PolicyServicePkg	30.42% <ø> (?)
SecurityPkg	1.56% <ø> (?)
StandaloneMmPkg	0.50% <ø> (?)
UefiCpuPkg	4.78% <ø> (?)
UnitTestFrameworkPkg	11.70% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Sean Brogan (spbrogan)]

this looks great.
I added a few comments

[Sean Brogan (spbrogan)]

In general, if the code goes into MdePkg it is expected to be industry specification defined so it would be something like EFI_RMEM_RECORD_HOB_GUID. This would indicate that this hob was defined (most likely) in the PI Specification (owned by UEFI forum).

So if we don't want to do that then this file would best fit into MdeModulePkg and this would be an Tianocore/Edk2 implementation feature.

[Sean Brogan (spbrogan)]

some comment here about Edkii vs EFI and MdePkg vs MdeModulePkg

[Sean Brogan (spbrogan)]

should probably call out the define that dictates the allowed max size and be clear if NULL is included in size or not.

[Sean Brogan (spbrogan)]

Just FYI - gEdkiiMemoryAcceptProtocolGuid seems like an outlier and did not follow the rules. I don't know exactly why it is in defined in this package.

[Eeshan Londhe (eeshanl)]

overall looks good, mainly just need to consolidate everything into one Pkg + some small nits.

[Eeshan Londhe (eeshanl)]

can we also add a section for how to view the acpi table entries from the os? example python/powershell commands.

[Eeshan Londhe (eeshanl)]

nit: add comments for these functions, ie describe how we reject overlapping regions, etc.