On 05/27/18 22:44, Andrew Fish wrote: > > >> On May 27, 2018, at 9:47 AM, Marvin H?user <marvin.haeu...@outlook.com> >> wrote: >> >> Good day Abhishek, >> >> I CC'd the MdeModulePkg maintainers, Ruiyu for the Platform BDS aspect >> (exposes the ReadyToLock protocol) and Laszlo for his high-quality answers. >> >> Strictly speaking you are, right, because of the description for the MM >> protocol: >> "Indicates that MM resources and services that should not be used by the >> third party code are about[Marvin: (!)] to be locked." >> Practically however, I don't see any issue with the current implementation. >> Code inside MMRAM is not affected directly by the lock, it is just notified. >> However, either the code or the specification should be slightly updated to >> be in sync. A code update might require review of the caller assumptions, >> just to be sure. >> >> I have a different concern though and hope I'm actually overlooking >> something. >> If I understand the code correctly, it is the Platform BDS that exposes the >> (S)MmReadyToLock protocol. PiSmmIpl seems to consume that event and lock SMM >> resources based on the event. >> Because of latter being an event however, I don't think it is, or can be, >> guaranteed to be the last event group member executing. >> When it is not the last, the "about to be locked" part is not true for any >> subsequent callbacks, that could actually be a risky break of the >> specification - if it is. >> If it is a break of the specification, I can only think of letting Platform >> BDS expose an "internal" event group, which is only caught by PiSmmIpl, >> which then drives the actual SmmReadyToLock flow. >> This would require updates to all platform trees and hence I would propose a >> temporary backwards-compatibility. >> >> Any comments? Did I overlook something (I hope)? >> > > Mavvin, > > You are correct there is no guarantee of order in events. Thanks for cc'ing > the right folks, as I don't remember all the low level details... > > In general the idea behind the MM code is it only comes from the platform, > then by definition that code should be aware when the platform was going to > lock MM. In a practical sense any MM module that had a depex evaluate to true > would have dispatched in DXE prior to BDS being launched. In general BDS is > the code that enumerates PCI and connects devices, thus there is no chance > for 3rd party software to run before that point in the boot. So in an > abstract sense that lock represents the end of DXE dispatch.
This is my understanding as well. gEfiDxeSmmReadyToLockProtocolGuid is installed by Plaform BDS before any non-platform binaries get a chance to run. In terms of the current PlatformBootManagerLib interfaces, that means the protocol should be installed from PlatformBootManagerBeforeConsole() (as noted on the API declaration itself). Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
