On 1/10/24 11:16, levi.yun wrote:
Hi, Laszlo.
This will keep initing the serial port upon every API call until the
global variable becomes writeable, and then the next API call will init
the serial port for one last time, and also prevent further page table
checks.
The CheckWritable() function is an implementation detail. In the DXE
phase, it could be implemented (I think?) with the
GetMemorySpaceDescriptor() DXE service, or perhaps even the
EFI_MEMORY_ATTRIBUTE_PROTOCOL.GetMemoryAttributes() UEFI protocol member
function. In the standalone MM core, CheckWritable() could walk the page
tables explicitly. The idea is, either way, to *predict* whether writing
to "mInitialized" would trap. >> I think it wouldn't proper, to DxeCore and
StMM too.
IIUC, before CoreInitializeMemoryServices is called, we couldn't use
that method in case DxeCore.
And the problem now I face is also StMM before populating memory
information (done in LibConstructor).
Now I think that speculative / out of order execution could actually
trigger the trap *before* GlobalsWriteable is calculated; however, I
think such a trap should be architecturally hidden (i.e., invisible). I
think at worst we could need a compiler barrier (maybe throw in some
"volatile" for GlobalsWriteable and mInitialized), so that the
*compiler* not try to reorder the accesses. But even that sounds like a
stretch.
Agree if we develop CheckPerm??
Currently, (In my narrow thinking) there is no more generic solution
than create new interface SerialPortInitilizeEarly.
Am I missing?
Many Thanks.
--------
Sincerely,
Levi.
Levi,
FWIW I prefer your original approach: explicitly call
SerialPortInitialize() early enough that you don't need to worry about
output occurring before that point. Then you can also use a
SerialPortLib instance which assumes that this has already been done and
doesn't try to re-initialize the port, which saves some overhead.
Constructors in DebugLib, SerialPortLib, and other very low-level
libraries are problematic due to the issue you ran in to, so it seems
best to just avoid them altogether.
Ard didn't want a SerialPortInitialize() call directly in the
all-platform StandaloneMmCore _ModuleEntryPoint() function, which is
understandable. So perhaps you could either:
1. Propose a platform-specific callout at that point and a library class
to implement it, with an empty instance for general use and your own
platform-specific instance which calls SerialPortInitialize().
or
2. Write your own platform-specific version of StandaloneMmCoreEntryPoint.
--
Brian J. Johnson
Enterprise X86 Lab
Hewlett Packard Enterprise
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113540): https://edk2.groups.io/g/devel/message/113540
Mute This Topic: https://groups.io/mt/103540969/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
