Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg: Initialise serial port early in StandaloneMmEntryPoint

["Brian J. Johnson" <brian.johnson@hpe.com>]

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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-