AdvLoggerPkg: Drop buffer migration#868
Open
makubacki wants to merge 1 commit intomicrosoft:release/202511from
Open
AdvLoggerPkg: Drop buffer migration#868makubacki wants to merge 1 commit intomicrosoft:release/202511from
makubacki wants to merge 1 commit intomicrosoft:release/202511from
Conversation
mu-automation
bot
added
impact:non-functional
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## release/202511 #868 +/- ##
================================================
Coverage ? 3.08%
================================================
Files ? 36
Lines ? 4246
Branches ? 73
================================================
Hits ? 131
Misses ? 4109
Partials ? 6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
makubacki
force-pushed
the
drop_adv_logger_buffer_migration
branch
from
b97e867 to
f923ebd
Compare
Contributor
✅ QEMU Validation PassedSource Dependencies
Results
Workflow run: https://github.com/microsoft/mu_plus/actions/runs/24160924905 This comment was automatically generated by the Mu QEMU PR Validation workflow. |
Effectively reverts commits af0f64c and 9fc8521 preserving structure compatibility and general cleanup. The advanced logger buffer starts accumulating messages in the first phase advanced logger is active, and the buffer continues to be used throughout remaining phases. Each phase has to account for either allocating or using an existing logger buffer. Due to the persistent nature of the buffer throughout boot, it is allocated as a runtime memory type early in boot to support its preservation and access at OS runtime. However, S4 resume relies upon a stable memory map across suspend and resume. Since the advanced logger buffer is allocated as a runtime memory type prior to DXE, it is in a buffer outside the DXE memory bins. This leads to an increased likelihood of the buffer being at a different address across suspend and resume affecting hibernate resume. Advanced logger buffer migration was a mechanism to address this but doing so complicates MM treatment of the buffer. Because a single advanced logger buffer is used across all phases, including a shared buffer between PEI and MM and DXE and MM, the buffer must be unlocked for MM access to accommodate a PEI MM IPL. This creates a problem where both requirements cannot simultaneously be met without additional complexity in MM access code. In addition, MM environments are inconsistent in their support for memory unlocking. In the end, hibernation has always been a best effort scenario with this flow and other MM solutions already require runtime allocations outside of DXE memory bins so this change removes the functional logic for migration. The memory bin scenario will be addressed in the future when the bins are allocated in a pre-DXE phase (e.g. PEI) and picked up by DXE. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
makubacki
force-pushed
the
drop_adv_logger_buffer_migration
branch
from
f923ebd to
4afb60c
Compare
cfernald
approved these changes
Apr 9, 2026
| EFI_TIME Time; // Uefi Time Field | ||
| UINT32 HwPrintLevel; // Logging level to be printed at hw port | ||
| UINT32 Reserved3; // | ||
| EFI_PHYSICAL_ADDRESS NewLoggerInfoAddress; // If non-zero, this field holds the address of new logger info that should be used |
Contributor
There was a problem hiding this comment.
Should we mark NewLoggerInfoAddress reserved/deprecated?
Contributor
There was a problem hiding this comment.
I think we should, as long as we say that Reserved fields cannot be used in the future.
os-d
approved these changes
Apr 9, 2026
cfernald
approved these changes
Apr 16, 2026
Contributor
cfernald
left a comment
cfernald
left a comment
There was a problem hiding this comment.
re-approving since github seems to have glitched and didn't count it before.
kuqin12
approved these changes
Apr 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Effectively reverts commits af0f64c and 9fc8521 preserving structure compatibility and general cleanup.
The advanced logger buffer starts accumulating messages in the first phase advanced logger is active, and the buffer continues to be used throughout remaining phases. Each phase has to account for either allocating or using an existing logger buffer. Due to the persistent nature of the buffer throughout boot, it is allocated as a runtime memory type early in boot to support its preservation and access at OS runtime.
However, S4 resume relies upon a stable memory map across suspend and resume. Since the advanced logger buffer is allocated as a runtime memory type prior to DXE, it is in a buffer outside the DXE memory bins. This leads to an increased likelihood of the buffer being at a different address across suspend and resume affecting hibernate resume. Advanced logger buffer migration was a mechanism to address this but doing so complicates MM treatment of the buffer.
Because a single advanced logger buffer is used across all phases, including a shared buffer between PEI and MM and DXE and MM, the buffer must be unlocked for MM access to accommodate a PEI MM IPL. This creates a problem where both requirements cannot simultaneously be met without additional complexity in MM access code. In addition, MM environments are inconsistent in their support for memory unlocking.
In the end, hibernation has always been a best effort scenario with this flow and other MM solutions already require runtime allocations outside of DXE memory bins, so this change removes the functional logic for migration.
The memory bin scenario will be addressed in the future when the bins are allocated in a pre-DXE phase (e.g. PEI) and picked up by DXE.
How This Was Tested
Integration Instructions