[2502] AdvLoggerPkg: Drop buffer migration#869
Merged
apop5 merged 1 commit intomicrosoft:release/202502from Apr 18, 2026
Merged
[2502] AdvLoggerPkg: Drop buffer migration#869apop5 merged 1 commit intomicrosoft:release/202502from
apop5 merged 1 commit intomicrosoft:release/202502from
Conversation
mu-automation
bot
added
impact:non-functional
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release/202502 #869 +/- ##
================================================
Coverage ? 4.99%
================================================
Files ? 36
Lines ? 3966
Branches ? 235
================================================
Hits ? 198
Misses ? 3766
Partials ? 2
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:
|
cfernald
approved these changes
Apr 9, 2026
Contributor
cfernald
left a comment
cfernald
left a comment
There was a problem hiding this comment.
approved pending comments in 2511 PR
kuqin12
approved these changes
Apr 9, 2026
os-d
approved these changes
Apr 9, 2026
Contributor
os-d
left a comment
os-d
left a comment
There was a problem hiding this comment.
With Chris's suggestion from the other PR on marking the field reserved
cfernald
approved these changes
Apr 16, 2026
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_2502
branch
from
ffc8fb6 to
6135290
Compare
Member
Author
Same change pushed here |
Member
Author
|
Note: Waiting for final server platform testing to conclude before merging |
Contributor
⏩ QEMU Validation SkippedValidation was skipped (reason: wrong_target_branch). This comment was automatically generated by the Mu QEMU PR Validation workflow. |
Collaborator
This is good to go, it was a switch of the MmUnblockMemoryLib from an actual instance to the NULL instance that was causing the test hang. Once it switched back, the system booted. |
apop5
approved these changes
Apr 18, 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
6 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