From: "Wu, Hao A" <hao.a.wu@intel.com>
To: "Zeng, Star" <star.zeng@intel.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Laszlo Ersek <lersek@redhat.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
"Wang, Jian J" <jian.j.wang@intel.com>,
"Ni, Ray" <ray.ni@intel.com>, Andrew Fish <afish@apple.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
Date: Thu, 21 Mar 2019 03:27:45 +0000 [thread overview]
Message-ID: <B80AF82E9BFB8E4FBD8C89DA810C6A093C8ACAF3@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB048310402980DA@shsmsx102.ccr.corp.intel.com>
> -----Original Message-----
> From: Zeng, Star
> Sent: Thursday, March 21, 2019 9:03 AM
> To: Leif Lindholm; Laszlo Ersek
> Cc: edk2-devel@lists.01.org; ard.biesheuvel@linaro.org; Wang, Jian J; Wu,
> Hao A; Ni, Ray; Andrew Fish; Kinney, Michael D; Zeng, Star
> Subject: RE: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> in .dsc
>
> 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
Hello Leif,
The current proposed patch seems great to me.
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
I am also fine with the above suggestion by Star. So if you prefer the
above approach, please feel free to propose another patch. Thanks in
advance.
Best Regards,
Hao Wu
>
>
> Thanks,
> Star
> -----Original Message-----
> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
> Sent: Thursday, March 21, 2019 1:43 AM
> To: Laszlo Ersek <lersek@redhat.com>
> Cc: edk2-devel@lists.01.org; ard.biesheuvel@linaro.org; Wang, Jian J
> <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Ni, Ray
> <ray.ni@intel.com>; Zeng, Star <star.zeng@intel.com>; Andrew Fish
> <afish@apple.com>; Kinney, Michael D <michael.d.kinney@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.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
next prev parent reply other threads:[~2019-03-21 3:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-18 14:56 [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc Leif Lindholm
2019-03-20 14:51 ` Laszlo Ersek
2019-03-20 15:41 ` Zeng, Star
2019-03-20 17:43 ` Leif Lindholm
2019-03-21 1:03 ` Zeng, Star
2019-03-21 3:27 ` Wu, Hao A [this message]
2019-03-22 18:13 ` Leif Lindholm
2019-03-25 2:17 ` Wu, Hao A
2019-03-26 19:43 ` Leif Lindholm
2019-03-27 1:00 ` Wu, Hao A
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B80AF82E9BFB8E4FBD8C89DA810C6A093C8ACAF3@SHSMSX104.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox