From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=40.92.68.61; helo=eur02-he1-obe.outbound.protection.outlook.com; envelope-from=marvin.haeuser@outlook.com; receiver=edk2-devel@lists.01.org Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068061.outbound.protection.outlook.com [40.92.68.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 019AE2098C8A8 for ; Wed, 18 Jul 2018 17:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6n6H3sTYan/QfbmKQ06JuyoTB9LtYSJI6gf/dWzlaF8=; b=p7BFh5otEmmWnI7ZNcfVGaXeFmZdyGjsWbqJcIo+C79MQS1/ndhrcQ32EpgFBgQ1QFWdH5qaFEyBdHDgmkrk7IQ7gN805FLG6X38URnEQ2P0oBvc5uYviNNkeAZtOgK72ETczmAY+DQ1OeOr3PaiRYSOCTJnmYYBnvZLiyRG3b5SIp1cR16yZSoutPf/b2xoLidYUtXkzfgF6u4bfdgyV7jMQ0nNXqlIYbJ6A4KuD3BjiVhbZS1qH5QrmX3512xxmPv7u7fo/gBBR7dvZ5kNqBGH5OG5ZCMYh+nPT1glwyLHsMtP+q2TjM5Ji4/IU9bmxo5qNb7nkrW4rB1p0PQ4gA== Received: from AM5EUR02FT040.eop-EUR02.prod.protection.outlook.com (10.152.8.55) by AM5EUR02HT081.eop-EUR02.prod.protection.outlook.com (10.152.9.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.952.17; Thu, 19 Jul 2018 00:10:23 +0000 Received: from VI1PR0801MB1790.eurprd08.prod.outlook.com (10.152.8.59) by AM5EUR02FT040.mail.protection.outlook.com (10.152.9.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.952.17 via Frontend Transport; Thu, 19 Jul 2018 00:10:23 +0000 Received: from VI1PR0801MB1790.eurprd08.prod.outlook.com ([fe80::7532:4dc6:e9f7:4765]) by VI1PR0801MB1790.eurprd08.prod.outlook.com ([fe80::7532:4dc6:e9f7:4765%2]) with mapi id 15.20.0952.021; Thu, 19 Jul 2018 00:10:23 +0000 From: Marvin H?user To: "edk2-devel@lists.01.org" CC: "Cohen, Eugene" , "star.zeng@intel.com" Thread-Topic: Inquiry regarding early DxeIplPeim loading. Thread-Index: AdQaNDyLZ2J/sHRiSC+kEdwPjgFgmQAVgqeAAAhusyABDCW5wAAF3OSg Date: Thu, 19 Jul 2018 00:10:23 +0000 Message-ID: References: <0C09AFA07DD0434D9E2A0C6AEB0483103BB82A5E@shsmsx102.ccr.corp.intel.com> In-Reply-To: Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:1B35F5EDEAD6A88A221BB5EBDDB294EA823967DB6E1356E35DEB214ED91CAB9C; UpperCasedChecksum:27F8CB0299701C611DF0119BB520EC8EF037EE620A7112B9C143092A8C878582; SizeAsReceived:7448; Count:46 x-tmn: [8O8onZMudkTtcCQoSxxmVmDIlcCpuRqe] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5EUR02HT081; 7:aX9acBcZr8Z1OiLAPakNE2Qeu7u4loT1t3ZuBIFcVW89WqrmvPT+omt2TdErlVJeKa1fVP0SYlf8jMoX8mzQs/hoIFO4vPlz65ssTJzRDYPnRcUvEl0oO1XmTMbnZp2VZIWjvXcLNQOU2sNEHvKAKxx4+H0quT8cPi/67EosKeEPVYVYmbXNYYgrwaXNQV9ShK0wGTPyhoewI6AMb/9pKxiVR9ksIKK3PwuVdcUNf/TkRfFvcFL+3yjD8KpHkYra x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125500)(1701031045); SRVR:AM5EUR02HT081; x-ms-traffictypediagnostic: AM5EUR02HT081: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(82015058); SRVR:AM5EUR02HT081; BCL:0; PCL:0; RULEID:; SRVR:AM5EUR02HT081; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(13464003)(189003)(199004)(26005)(7696005)(5640700003)(5250100002)(4326008)(6346003)(6306002)(102836004)(76176011)(55016002)(93886005)(2501003)(14454004)(105586002)(106356001)(86362001)(53546011)(575784001)(25786009)(82202002)(8676002)(81156014)(99286004)(54906003)(20460500001)(305945005)(72206003)(6436002)(229853002)(104016004)(74316002)(966005)(486006)(97736004)(11346002)(6916009)(476003)(87572001)(6246003)(33656002)(426003)(14444005)(256004)(5660300001)(8936002)(68736007)(2351001)(446003)(2900100001)(19627235002)(56003); DIR:OUT; SFP:1901; SCL:1; SRVR:AM5EUR02HT081; H:VI1PR0801MB1790.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: outlook.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Marvin.Haeuser@outlook.com; x-microsoft-antispam-message-info: CY/mQ97evTNn9l2mgUh3mf4PjlizfWryfR+pJEf25CPIaAZY4e5WCt75lZ1x4HOtlKJVLAz0jcdPsB704/IolrDnjt6m3sLNhvmW/cwHZN9KTqlB9dKjk8SqDfMfBnpSlFt2oLVScZTi1X8hb62dHmN3sEEf7dj7MqKUreJ6lMwzaj8J+/bBjHnv3EH7gwBwpJgxZgRpC29GohvsyngKy0Tx9G+ltztoNILaEeAGyoI= MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 7181d4b0-87d6-4f4e-ba33-0d3746212cec X-MS-Exchange-CrossTenant-Network-Message-Id: e254b36b-641b-40bd-2ecf-08d5ed0c0602 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 7181d4b0-87d6-4f4e-ba33-0d3746212cec X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 00:10:23.8208 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT081 Subject: Re: Inquiry regarding early DxeIplPeim loading. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 00:10:27 -0000 Content-Language: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Eugene, I do not think this is a hack, I don't think it uses DxeIplPeim for "actual= booting", but more for the compression PPIs it exposes. FVs might be compressed for performance reason and be loaded into memory (D= RAM or cache). Though to be honest, I am not sure why these PPIs are exposed by DxeIplPeim= instead of a dedicated module or maybe even PeiCore itself, if it's the de= facto standard. Also, if the change was done to avoid disabling CAR prematurely, why wasn't= SEC code adapted? UefiCpuPkg SecCore calls the PlatformSecLib function to disable CAR when pe= rmanent memory has been installed. >>From what I can see, the described change only makes sense if InstallMemory= is not called during the entire PEI phase. Am I missing something? Thanks, Marvin > -----Original Message----- > From: Cohen, Eugene > Sent: Wednesday, July 18, 2018 11:37 PM > To: Marvin H?user ; edk2- > devel@lists.01.org > Cc: eric.dong@intel.com; Zeng, Star ; Cohen, Eugene > > Subject: RE: Inquiry regarding early DxeIplPeim loading. >=20 > The depex change did not pertain to S3 resume without memory initializati= on > (obviously that wouldn't work). The change was whether "permanent > memory" was installed from a PI architecture perspective. We had a > situation that required that the S3 Resume path remain in PEI Cache-as-RA= M > (actual code in CAR, not just data) and this change was necessary to prev= ent > CAR from being turned off prematurely on S3 resume. >=20 > By the way it was never our goal for DXE IPL to host the S3 resume path -= my > understanding is that this was a matter of convenience back in ancient > history of S3 development (according to an old thread I dug up from a few > years ago). If S3 resume were parked somewhere else such that DXE IPL > only did the IPL of DXE then this issue might go away. So you're seeing = a > secondary effect of hosting S3 resume in DXE IPL and DXE IPL depex change= s > to support an unusual use case. >=20 >=20 > > -----Original Message----- > > From: edk2-devel On Behalf Of Marvin > > H?user > > Sent: Friday, July 13, 2018 7:26 AM > > To: edk2-devel@lists.01.org > > Cc: eric.dong@intel.com; Zeng, Star > > Subject: Re: [edk2] Inquiry regarding early DxeIplPeim loading. > > > > Hey Star, > > > > Thank you very much for your reply. > > Interesting, that is basically the case I described as "insane" > > because I did not consider any platform to allow S3 resume without > > memory initialization. So, this code definitely makes sense. > > You are right, according to the specification, moving it to the > > PostMem FV should be fine. However that will cost a shadow call and a > > re-entry for non- > > S3 and an event registration for the S3 boot path. > > As the information whether S3 resume without meminit is intended is > > known at compile-time, what's your opinion on a FeatureFlag PCD which > > chooses between direct calls and the shadow/event system? > > I would prepare a patch as soon as I can properly test its working, if > > you are interested. The changes would be most minimal, I imagine. > > > > Thanks, > > Marvin. > > > > > -----Original Message----- > > > From: Zeng, Star > > > Sent: Friday, July 13, 2018 11:24 AM > > > To: Marvin H?user ; edk2- > > > devel@lists.01.org > > > Cc: Dong, Eric ; Cohen, Eugene > > ; > > > Gao, Liming ; Zeng, Star > > > Subject: RE: Inquiry regarding early DxeIplPeim loading. > > > > > > Marvin, > > > > > > You can check SHA-1: ebaafbe62c70309d0ceb44a0c4199093d0a823c4. > > > It is for the case "Allow S3 Resume without having installed > > > permanent memory (via InstallPeiMemory)" (PI Mantis 1532, you can > > > search the sentence in PI spec) requested by HP. > > > Yes before ebaafbe62c70309d0ceb44a0c4199093d0a823c4, DxeIpl.inf had > > > gEfiPeiMemoryDiscoveredPpiGuid DEPEX. > > > For the case you mentioned about MinPlatformPkg, I think you can put > > > the DxeIpl.inf into a Post Memory FV if the platform will publish > > > gEfiPeiMemoryDiscoveredPpiGuid indeed. > > > > > > > > > Thanks, > > > Star > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf > > Of > > > Marvin H?user > > > Sent: Friday, July 13, 2018 7:19 AM > > > To: edk2-devel@lists.01.org > > > Cc: Dong, Eric ; Zeng, Star > > > > > > Subject: [edk2] Inquiry regarding early DxeIplPeim loading. > > > > > > Good day developers, > > > > > > While checking out which edk2 modules request being shadowed, I came > > > across DxeIplPeim being one of them, however I am not sure why it > > > was designed this way. > > > > > > If the Boot Mode is !=3D S3, the module will register for shadowing > > > and immediately return during the pre-memory phase > > > > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/D > > xe > > > IplPeim/DxeLoad.c#L92 > > > > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/D > > xe > > > IplPeim/DxeLoad.c#L111 > > > > > > If the Boot Mode is S3, the module will register a Memory Discovered > > > event to install crucial PPIs... > > > > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/D > > xe > > > IplPeim/DxeLoad.c#L125 > > > ... and install the DxeIpl PPI before returning > > > > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/D > > xe > > > IplPeim/DxeLoad.c#L132 > > > > > > However, by design, the DxeIpl PPI is not located until the very end > > > of PeiCore, meaning the dispatcher ran out of modules to dispatch > > > > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/P > > ei/ > > > PeiMain/PeiMain.c#L467 > > > Hence installing the DxeIpl PPI early in the S3 boot path does not > > > seem to have any effect to me, as both paths are left awaiting > > > memory availability (Shadow / event). The only functional change > > > would be PeiCore failing to locate the DxeIpl PPI in case memory > > > initialization silently fails and code execution continues, which is > > > an insane state in the > > first place. > > > > > > Am I missing any scenario where this design is helpful? Is there any > > > disadvantage for adding a Depex on MemoryDiscovered PPI? Running > > only > > > after memory initialization would shrink the initialization function > > > by removing the shadowing request in non-S3 path and the event > > > registration in the S3 path, as well as merging the PPI installation > > > code as both registrations end up executing the exact same code > > > > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/D > > xe > > > IplPeim/DxeLoad.c#L118 > > > > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/D > > xe > > > IplPeim/DxeLoad.c#L57 > > > > > > The initialization function would collapse to PPI installations, a > > > shadow or event registration call would be saved and platforms could > > > safely embed DxeIplPeim into a Post Memory FV, such as > > MinPlatformPkg > > > is using, to have the PEIM loaded directly into memory to gain yet > > > more performance. The only restriction would be to prohibit > > compression. > > > > > > Thanks for your time. > > > > > > Best regards, > > > Marvin. > > > _______________________________________________ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel