Another way to update the file is [LibraryClasses.EBC] LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
-> [LibraryClasses.EBC, LibraryClasses.ARM, LibraryClasses.AARCH64] LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf Thanks, Star -----Original Message----- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: Thursday, March 21, 2019 1:43 AM To: Laszlo Ersek <ler...@redhat.com> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J <jian.j.w...@intel.com>; Wu, Hao A <hao.a...@intel.com>; Ni, Ray <ray...@intel.com>; Zeng, Star <star.z...@intel.com>; Andrew Fish <af...@apple.com>; Kinney, Michael D <michael.d.kin...@intel.com> Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote: > Hi Leif, > > On 03/18/19 15:56, Leif Lindholm wrote: > > Commit 05fd2a926833 > > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList > > LockBox") added a dependency on LockBoxLib to NvmExpressPei, causing > > builds using MdeModulePkg.dsc to fail on architectures other than > > IA32/X64 with missing reference to > > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode. > > > > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Leif Lindholm <leif.lindh...@linaro.org> > > --- > > > > Note: this patch hides the symptom, but this isn't really the fix I > > would like to see. > > > > The build error is caused by the chain of: > > 1) NvmExpressPei depending on LockBoxLib > > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in > > [LibraryClasses.common.PEIM] > > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode > > 4) PcdDxeIplSwitchToLongMode being declared in > > [PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc > > > > Now, an alternative quick-fix would be to move the PEIM LockBoxLib > > mapping into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM] > > section. But that would leave NvmExpressPei unbuildable on anything > > not IA32/X64. > > > > Another option would be to add default declaration (for all other > > architectures) of FALSE for PcdDxeIplSwitchToLongMode in > > MdeModulePkg.dec, but the current way this is expressed seems to > > treat this as an architecture-specific feature (which it is). > > > > What I believe would be the cleanest solution would be to abstract > > NvmExpressPei to the point where it can function without the LockBoxLib. > > But regardless, it does not look valid to me for something as > > architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live > > under .common sections in the .dsc. (And if this changes at some > > point, because we implement an ARM/AARCH64 equivalent based on > > StandaloneMmPkg, we will need a major refactoring of that library > > anyway.) > > > > / > > Leif > > > > MdeModulePkg/MdeModulePkg.dsc | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MdeModulePkg/MdeModulePkg.dsc > > b/MdeModulePkg/MdeModulePkg.dsc index 6cd1727a0d..6e27e9cb68 100644 > > --- a/MdeModulePkg/MdeModulePkg.dsc > > +++ b/MdeModulePkg/MdeModulePkg.dsc > > @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE] > > [LibraryClasses.ARM, LibraryClasses.AARCH64] > > ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf > > ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > > + LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf > > > > # > > # It is not possible to prevent ARM compiler calls to generic intrinsic > > functions. > > > > I think this patch is exactly the right solution. > > The code added in commit 05fd2a926833 is gated by (BootMode == > BOOT_ON_S3_RESUME). That condition can never evaluate to TRUE on > ARM/AARCH64, presently. Accordingly, the stated goal of the commit > doesn't apply to ARM/AARCH64: > > The purpose is to perform an on-demand (partial) NVM Express device > enumeration/initialization to benefit the S3 resume performance. > > Given that the RestoreLockBox() calls are never reached (which is > correct, by design, at the present level of ACPI S3 enablement in edk2 > for ARM/AARCH64), causing the lockbox APIs to "do nothing beyond > compile" is exactly right. IMO anyway. > > Once ARM/AARCH64 grow S3 support, a functional and secure LockBox will > have to be part of that. Perhaps it will use "standalone MM"; I'm not > sure. The point is, once the goal of the commit starts applying to > ARM/AARCH64, a functional LockBox will have been implemented for > ARM/AARCH64; and that lib instance will certainly not depend on > PcdDxeIplSwitchToLongMode. > > Until such time, this patch is fine. OK, I buy that argument. *But* I still think the IA32/X64 specific library mappings should be moved out of .common LibraryClass sections. Regards, Leif > Reviewed-by: Laszlo Ersek <ler...@redhat.com> > > Thanks > Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
