From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=hao.a.wu@intel.com; receiver=edk2-devel@lists.01.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4CC1A211DBDE4 for ; Sun, 24 Mar 2019 19:17:12 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2019 19:17:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,256,1549958400"; d="scan'208";a="125548914" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga007.jf.intel.com with ESMTP; 24 Mar 2019 19:17:12 -0700 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 24 Mar 2019 19:17:11 -0700 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by FMSMSX113.amr.corp.intel.com (10.18.116.7) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 24 Mar 2019 19:17:11 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.74]) by SHSMSX153.ccr.corp.intel.com ([169.254.12.121]) with mapi id 14.03.0415.000; Mon, 25 Mar 2019 10:17:05 +0800 From: "Wu, Hao A" To: Leif Lindholm CC: "Zeng, Star" , Laszlo Ersek , "edk2-devel@lists.01.org" , "ard.biesheuvel@linaro.org" , "Wang, Jian J" , "Ni, Ray" , Andrew Fish , "Kinney, Michael D" Thread-Topic: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc Thread-Index: AQHU3ZrQFeEhXy5lsku2RALYksrpd6YUF4aAgAAv+ACAAHrcAIAArXswgAIEqoCABDE6AA== Date: Mon, 25 Mar 2019 02:17:05 +0000 Message-ID: References: <20190318145625.29000-1-leif.lindholm@linaro.org> <87af2f8b-a8f7-a437-a4ab-019178bb1f13@redhat.com> <20190320174320.rzuprck56u2f5d5u@bivouac.eciton.net> <0C09AFA07DD0434D9E2A0C6AEB048310402980DA@shsmsx102.ccr.corp.intel.com> <20190322181311.bu5d55bjngfwlqt2@bivouac.eciton.net> In-Reply-To: <20190322181311.bu5d55bjngfwlqt2@bivouac.eciton.net> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 02:17:13 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Leif Lindholm [mailto:leif.lindholm@linaro.org] > Sent: Saturday, March 23, 2019 2:13 AM > To: Wu, Hao A > Cc: Zeng, Star; Laszlo Ersek; edk2-devel@lists.01.org; > ard.biesheuvel@linaro.org; Wang, Jian J; Ni, Ray; Andrew Fish; Kinney, Mi= chael > D > Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 > in .dsc >=20 > On Thu, Mar 21, 2019 at 03:27:45AM +0000, Wu, Hao A wrote: > > > -----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/X= 64 > > > 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 > > > > 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. >=20 > Laszlo convinced me that this change makes sense. But the argument for > that was that each architecture needs to decide itself how to > implement LockBoxLib (or not). >=20 > What does not make sense to me is that > MdeModulePkg/Library/SmmLockBoxLib/ is used as a global default, and > set as the resolution for LockBoxLib in common sections, when it is > only valid for 2 of the 6 architectures supported by the UEFI > specification. Hello Leif, I filed a BZ tracker according to your above concern: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1660 We will find an approach to address it. >=20 > My original version is my preferred way of addressing the immediate > problem though, mainly to keep the separate .EBC section. Got it. Do you want me to help to push the patch? Best Regards, Hao Wu >=20 > Best Regards, >=20 > Leif >=20 > > 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 > > > Cc: edk2-devel@lists.01.org; ard.biesheuvel@linaro.org; Wang, Jian J > > > ; Wu, Hao A ; Ni, Ray > > > ; Zeng, Star ; Andrew Fish > > > ; Kinney, Michael D > > > Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X= 64 > > > 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 bu= ilds. > > > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > > Signed-off-by: Leif Lindholm > > > > > --- > > > > > > > > > > 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.ds= c > > > > > > > > > > Now, an alternative quick-fix would be to move the PEIM LockBoxLi= b > > > > > mapping into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM= ] > > > > > section. But that would leave NvmExpressPei unbuildable on anythi= ng > > > > > 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 abstrac= t > > > > > 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 l= ive > > > > > 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 =3D=3D > > > > 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 de= vice > > > > 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 e= dk2 > > > > 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 n= ot > > > > 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 > > > > > > > > Thanks > > > > Laszlo