Revert Downgrading Page.c Error Prints #1095
Merged
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
This reverts commit 76f8060.
This commit was from an earlier era of Project Mu where we were not as strict with memory protections. Now that we are more strict, these are important prints (and failures if alignment of a RUNTIME entry is wrong). This was confirmed by booting on Q35 and analyzing the few prints that showed up.
The first was that Rust code was not being linked as we expected, that is fixed here for pure Rust repos: microsoft/mu_devops#356 and here for mu_basecore based repos: #1098. This may get fixed in a different way that is more broad. The in-depth issue was that /BASE:0 was not getting set for the Rust linker. It is failing to allocate pages when loading the image. The reason is that the ImageBase field in the PE/COFF optional header is set, so we try to load at that address:
mu_basecore/MdeModulePkg/Core/Dxe/Image/Image.c
Lines 730 to 748 in 45e4430
mu_basecore/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
Lines 619 to 629 in 45e4430
Per the PE/COFF spec, this is only intended for use by Windows and I don't think we should really be honoring it, but probably things are relying on it:
UefiHidDxe and HelloWorldRustDxe are the only EFI binaries in the mu_tiano_platforms build that set ImageBase. For everything else it is 0, so we don't enter that codepath (what happens in that codepath is the ImageBase provided, 0x140000000 for both modules, is where we attempt to load the modules to, which isn't in our memory tree (or one of those two is already loaded there) and so we fail).Setting /BASE:0 causes MSVC to set the ImageBase to 0 (in ElfConvert we always set the ImageBase to 0:
mu_basecore/BaseTools/Source/C/GenFw/Elf64Convert.c
Line 1180 in 45e4430
The other set of failures was from gDS->SetMemorySpaceCapabilities() trying to set attributes in gMemoryMap on GCD memory types that don't exist there and an edk2 PR has been put up to fix that: tianocore/edk2#6062.
There are no other failures seen and when these failures do occur, we want to debug them. Closes #1091.
For each item, place an "x" in between
[
and]
if true. Example:[x]
.(you can also check items in the GitHub UI)
flow, or firmware?
validation improvement, ...
in build or boot behavior?
a function in a new library class in a pre-existing module, ...
outside direct code modifications (and comments)?
on an a separate Web page, ...
How This Was Tested
Tested on Q35.
Integration Instructions
N/A.