Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc

[Leif Lindholm <leif.lindholm@linaro.org>]

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.lindholm@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 <lersek@redhat.com>
> 
> Thanks
> Laszlo