From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=40.107.0.71; helo=eur02-am5-obe.outbound.protection.outlook.com; envelope-from=wasim.khan@nxp.com; receiver=edk2-devel@lists.01.org Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00071.outbound.protection.outlook.com [40.107.0.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C09DE2035D32B for ; Mon, 8 Jan 2018 22:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5eTVqxxRNDvtPx0+zGX8p1CJeBusuRCTLw5IlKgLXYU=; b=JsCF0VwGf6wCGOfu2eE87WCow3qo/aYRIkH/35HpA6grSaHXpL47vZ6XxM0O6+GmIOIXQ0LRn6m6AEU/wseHGF6xO7SoeQfoCDOFM+lg0gI0BxRt4HUIUN/Ro3ddRSi6hFoNvGBet269guqNs/gw+GcunEAEfaUidd6f+d13p9Y= Received: from HE1PR0401MB2346.eurprd04.prod.outlook.com (10.168.32.153) by HE1PR0401MB2347.eurprd04.prod.outlook.com (10.168.32.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Tue, 9 Jan 2018 06:58:45 +0000 Received: from HE1PR0401MB2346.eurprd04.prod.outlook.com ([fe80::8537:bbde:57c6:b421]) by HE1PR0401MB2346.eurprd04.prod.outlook.com ([fe80::8537:bbde:57c6:b421%17]) with mapi id 15.20.0386.006; Tue, 9 Jan 2018 06:58:45 +0000 From: Wasim Khan To: "Zeng, Star" , "edk2-devel@lists.01.org" CC: "Gao, Liming" Thread-Topic: Memory space entry is not removed after calling FreeMemorySpace and RemoveMemorySpace Thread-Index: AdOGC9ELVQ4yvX0oRxySz+o11ogX7AAB/zdQAHS4DAAADWQ3gAAYAkIwAAJA2jAAI5H3oA== Date: Tue, 9 Jan 2018 06:58:45 +0000 Message-ID: References: <0C09AFA07DD0434D9E2A0C6AEB0483103B9F8894@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B9F8CA8@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B9F9191@shsmsx102.ccr.corp.intel.com> In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B9F9191@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wasim.khan@nxp.com; x-originating-ip: [192.88.169.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0401MB2347; 7:eB3jiH5c3kiZ4D5XElJVRgCWIq07JN1Ifv191xStrJ1k4ydB5/xymOkcX2gcK+NfYkn9ZJTrr4+PsWeI4/CHSUAbEao9AvELlNmndG2n6yvLHkG+MLDnRBa2PzlfgpWkDunZhjctm+EMvZ4Qs/cwAJDK0Y9FOKhX0T6t+c0uDWPiq5BSI6CGPwPbmZOWjd0sB/een2Kldl7TLtbZiKa3dk50tNj1Qhp4eK3+2d/O+DB/opOIb791wLLYcNmsENce x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 61bdee93-105f-49da-e552-08d5572e6d07 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0401MB2347; x-ms-traffictypediagnostic: HE1PR0401MB2347: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(189930954265078)(185117386973197)(162533806227266)(45079756050767)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6055026)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0401MB2347; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0401MB2347; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39380400002)(39860400002)(346002)(396003)(366004)(13464003)(53754006)(189003)(199004)(57704003)(53946003)(2501003)(59450400001)(6506007)(53546011)(478600001)(6246003)(3280700002)(7696005)(55016002)(2906002)(97736004)(5250100002)(6306002)(9686003)(3660700001)(53936002)(81156014)(81166006)(8676002)(345774005)(2950100002)(8936002)(110136005)(45080400002)(316002)(93886005)(102836004)(305945005)(7736002)(4326008)(68736007)(105586002)(229853002)(25786009)(33656002)(3846002)(66066001)(76176011)(74316002)(575784001)(2900100001)(106356001)(6116002)(6436002)(966005)(86362001)(99286004)(14454004)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0401MB2347; H:HE1PR0401MB2346.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: aGhETykPleXLbaInMMAWKk/KyfKmrI1cf68J+rji2K2NkpcUjnyGNnWIXvuoKuxRvHyJA2JgIhVhNtZAwyD8eA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61bdee93-105f-49da-e552-08d5572e6d07 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 06:58:45.0733 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0401MB2347 Subject: Re: Memory space entry is not removed after calling FreeMemorySpace and RemoveMemorySpace X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 06:53:39 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Star, I agree with both the use cases. I think only 'gDS->FreeMemorySpace' need to be updated, currently it direct= ly sets the 'ImageHandle =3D NULL' instead it should do below. - If the memory is not in use by drivers, do the cleanup and set the 'Image= Handle =3D NULL' - If the memory is in use by drivers, do not set the 'ImageHandle =3D NULL= ' and return error like 'Memory is in use'. I think no need to change anything for 'gDS->RemoveMemorySpace' call, as it= returns error (EFI_ACCESS_DENIED) if the ImageHandle !=3D NULL. So it will= automatically pass for case1 and fails for case2. Regards, Wasim > -----Original Message----- > From: Zeng, Star [mailto:star.zeng@intel.com] > Sent: Monday, January 08, 2018 7:16 PM > To: Wasim Khan ; edk2-devel@lists.01.org > Cc: Gao, Liming ; Zeng, Star > Subject: RE: Memory space entry is not removed after calling FreeMemorySp= ace > and RemoveMemorySpace >=20 > There are two cases here. >=20 > Case 1: > 1. gDS->AddMemorySpace > The memory range is automatically allocated for use by the UEFI memory > services. > 2. No any driver allocates memory at this memory range by gBS- > >AllocatePages()/AllocatePool(). > 3. gDS->FreeMemorySpace > 4. gDS->RemoveMemorySpace >=20 > Case 2: > 1. gDS->AddMemorySpace > The memory range is automatically allocated for use by the UEFI memory > services. > 2. There are driver(s) allocate memory at this memory range by gBS- > >AllocatePages()/AllocatePool. > 3. gDS->FreeMemorySpace > 4. gDS->RemoveMemorySpace >=20 > For case 1, the memory range could be removed safely from UEFI memory map > at step 3, and step 3 and 4 could return success. > For case 2, the memory range could be not removed from UEFI memory map at > step3 as the memory range is still been used by drivers, then step 3 and = 4 should > return failure. >=20 >=20 > Thanks, > Star > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Wasim Khan > Sent: Monday, January 8, 2018 8:48 PM > To: Zeng, Star ; edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: Re: [edk2] Memory space entry is not removed after calling > FreeMemorySpace and RemoveMemorySpace >=20 > Hi Star, >=20 > I agree with you that 'gDS->AddMemorySpace' should always pass, but if th= ese > functions are made to return the Status, we should ideally check the Stat= us and > take necessary actions upon failure. >=20 > After going through the code, if a memory space for > EfiGcdMemoryTypeSystemMemory (or EfiGcdMemoryTypeMoreReliable) is > added then memory range is automatically allocated for use by the UEFI > memory services by adding a memory descriptor to gMemoryMap . > But when we call 'gDS->FreeMemorySpace' and ''gDS->RemoveMemorySpace' , > memory space is only removed from GCD map and it is not removed from UEFI > Services map. >=20 > So ideally while when a call to gDS->AddMemorySpace (for memory type > EfiGcdMemoryTypeSystemMemory) automatically allocates it for use by UEFI > memory services. It should also free the memory when 'gDS- > >FreeMemorySpace' call is made. >=20 > I have opened a ticket for this issue > (https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fbug= zill > a.tianocore.org%2Fshow_bug.cgi%3Fid%3D841&data=3D02%7C01%7Cwasim.kha > n%40nxp.com%7Cd45b6709b297491dba9b08d5569e20f7%7C686ea1d3bc2b4c6 > fa92cd99c5c301635%7C0%7C1%7C636510159548814134&sdata=3DB2yvF5RzoRJa > IeNJejOR8hedKCJygbkCCkYieTNFXzw%3D&reserved=3D0) . >=20 >=20 > Regards, > Wasim >=20 > > -----Original Message----- > > From: Zeng, Star [mailto:star.zeng@intel.com] > > Sent: Monday, January 08, 2018 6:37 AM > > To: Wasim Khan ; edk2-devel@lists.01.org > > Cc: Gao, Liming ; Zeng, Star > > > > Subject: RE: Memory space entry is not removed after calling > > FreeMemorySpace and RemoveMemorySpace > > > > Hi Wasim, > > > > Got the point. > > > > Yes, gDS->AddMemorySpace should return success normally, you may can > > assume it. > > Or a little tricky method if you only want the memory space to be used > > by OS kernel, but not post, I think you may can hook the > > gBS->GetMemoryMap() with your own GetMemoryMap() function, it will > > call original GetMemoryMap() function, and then append one entry for > > the memory space you want to add for OS kernel. > > > > > > > > Thanks, > > Star > > -----Original Message----- > > From: Wasim Khan [mailto:wasim.khan@nxp.com] > > Sent: Monday, January 8, 2018 3:03 AM > > To: Zeng, Star ; edk2-devel@lists.01.org > > Cc: Gao, Liming > > Subject: RE: Memory space entry is not removed after calling > > FreeMemorySpace and RemoveMemorySpace > > > > Hi Star, > > > > Thank you for your reply. > > > > I cannot add memory space as EfiGcdMemoryTypeReserved because for my > > use case, i am exposing memory space of an extended DDR memory to > > kernel. If I add this memory space as EfiGcdMemoryTypeReserved, then > > linux is not able to allocate memory from this region to applications > > (a simple application requesting memory from this region fails). So I > > have to add the memory space as EfiGcdMemoryTypeSystemMemory only. > > > > > What is the usage that the memory space needs to be added first and > > > removed > > later? > > No specific use case, I am checking the status of > > 'gDS->AddMemorySpace' and 'gDS->SetMemorySpaceAttributes', if any of > > these calls fails, I want to remove the added memory space. Ideally it = should > work. > > > > > > > > Regards, > > Wasim > > > > > > > > > -----Original Message----- > > > From: Zeng, Star [mailto:star.zeng@intel.com] > > > Sent: Friday, January 05, 2018 4:35 PM > > > To: Wasim Khan ; edk2-devel@lists.01.org > > > Cc: Zeng, Star ; Gao, Liming > > > > > > Subject: RE: Memory space entry is not removed after calling > > > FreeMemorySpace and RemoveMemorySpace > > > > > > PI spec has clear description below in AddMemorySpace(). > > > > > > "If the memory range specified by BaseAddress and Length is of type > > > EfiGcdMemoryTypeSystemMemory or EfiGcdMemoryTypeMoreReliable, > then > > the > > > memory range may be *automatically allocated for use by the UEFI > > > memory services*." > > > > > > But PI spec has no clear description about removing the use from the > > > UEFI memory services in FreeMemorySpace() and RemoveMemorySpace(). > > > I think it is very hard (may be not possible) as the added memory > > > space may have been used by UEFI memory (page) services for drivers > > > after the memory space is added by AddMemorySpace(). > > > > > > What is the usage that the memory space needs to be added first and > > > removed later? > > > Could the memory space be added as EfiGcdMemoryTypeReserved type > > > instead of EfiGcdMemoryTypeSystemMemory type? > > > > > > > > > Thanks, > > > Star > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf > > > Of Wasim Khan > > > Sent: Friday, January 5, 2018 5:59 PM > > > To: edk2-devel@lists.01.org > > > Subject: [edk2] Memory space entry is not removed after calling > > > FreeMemorySpace and RemoveMemorySpace > > > > > > Hi All, > > > > > > I am facing a problem that if a add a memory space using 'gDS- > > > >AddMemorySpace' and then remove it using 'gDS->FreeMemorySpace' > > > followed by 'gDS->RemoveMemorySpace'. > > > I can still see the entry of added memory space in the table shown > > > by > > 'memmap' > > > command. > > > > > > I enabled DEBUG_GCD and as per logs , the entry is removed from > > > GcdMemorySpaceMap , but when I run 'memmap' command which gets the > > > memory map using 'gBS->GetMemoryMap', I can see that entry for the > > > added memory space is still present. Steps and Logs are below for > > > reference > > > > > > Do I need to perform any other steps in order to cleanly remove the > > > memory space entry ? > > > > > > Regards, > > > Wasim > > > > > > > > > > > > Below are the steps and GCD debug logs. > > > Steps 1 : Add a memory space . We can see that an entry from system > > > memory is added. > > > > > > Status =3D gDS->AddMemorySpace ( > > > EfiGcdMemoryTypeSystemMem= ory, > > > FixedPcdGet64(PcdSystemMe= moryExBase), > > > SystemMemoryExSize, > > > EFI_MEMORY_WC | EFI_MEMOR= Y_WT | > > > EFI_MEMORY_WB > > > ); > > > > > > Logs: > > > > > > > > > GCD:AddMemorySpace(Base=3D0000008080000000,Length=3D0000000380000000) > > > GcdMemoryType =3D SystemMem > > > Capabilities =3D 000000000000000E > > > CoreConvertSpace 774 > > > Status =3D Success > > > GCDMemType Range Capabilities Attribu= tes > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > NonExist 0000000000000000-000000009FFFFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 00000000A0000000-00000000DFFFFFFF 800000000000000E > > > 0000000000000008* > > > NonExist 00000000E0000000-00000000E01BFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 00000000E01C0000-00000000FFFFFFFF 800000000000000E > > > 0000000000000008* > > > NonExist 0000000100000000-000000807FFFFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 0000008080000000-00000083FFFFFFFF 800000000000000E > > > 0000000000000000 > > > NonExist 0000008400000000-0000FFFFFFFFFFFF 0000000000000000 > > > 0000000000000000 > > > > > > > > > GCD:AllocateMemorySpace(Base=3D0000008080000000,Length=3D00000003800000 > > > 00) > > > GcdAllocateType =3D AtAddress > > > GcdMemoryType =3D SystemMem > > > Alignment =3D 0000000000001000 > > > ImageHandle =3D FED1FF98 > > > DeviceHandle =3D 0 > > > Status =3D Success (BaseAddress =3D 0000008080000000) > > > GCDMemType Range Capabilities Attribu= tes > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > NonExist 0000000000000000-000000009FFFFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 00000000A0000000-00000000DFFFFFFF 800000000000000E > > > 0000000000000008* > > > NonExist 00000000E0000000-00000000E01BFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 00000000E01C0000-00000000FFFFFFFF 800000000000000E > > > 0000000000000008* > > > NonExist 0000000100000000-000000807FFFFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 0000008080000000-00000083FFFFFFFF 800000000000000E > > > 0000000000000000* > > > NonExist 0000008400000000-0000FFFFFFFFFFFF 0000000000000000 > > > 0000000000000000 > > > > > > > > > Step2: Free the memory space > > > Status =3D gDS->FreeMemorySpace ( > > > FixedPcdGet64(PcdSystemMemoryExBase), > > > SystemMemoryExSize > > > ); > > > > > > Logs: > > > > > > > > > GCD:FreeMemorySpace(Base=3D0000008080000000,Length=3D0000000380000000) > > > Status =3D Success > > > GCDMemType Range Capabilities Attribu= tes > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > NonExist 0000000000000000-000000009FFFFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 00000000A0000000-00000000DFFFFFFF 800000000000000E > > > 0000000000000008* > > > NonExist 00000000E0000000-00000000E01BFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 00000000E01C0000-00000000FFFFFFFF 800000000000000E > > > 0000000000000008* > > > NonExist 0000000100000000-000000807FFFFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 0000008080000000-00000083FFFFFFFF 800000000000000E > > > 0000000000000000 > > > NonExist 0000008400000000-0000FFFFFFFFFFFF 0000000000000000 > > > 0000000000000000 > > > > > > > > > Step3: Remove the memory space , As we can see that entry 'SystemMem > > > 0000008080000000-00000083FFFFFFFF' is removed. > > > Status =3D gDS->RemoveMemorySpace ( > > > FixedPcdGet64(PcdSystemMemoryExBase), > > > SystemMemoryExSize > > > ); > > > > > > Logs: > > > > > > > > > GCD:RemoveMemorySpace(Base=3D0000008080000000,Length=3D00000003800000 > > > 00) > > > Status =3D Success > > > GCDMemType Range Capabilities Attribu= tes > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > NonExist 0000000000000000-000000009FFFFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 00000000A0000000-00000000DFFFFFFF 800000000000000E > > > 0000000000000008* > > > NonExist 00000000E0000000-00000000E01BFFFF 0000000000000000 > > > 0000000000000000 > > > SystemMem 00000000E01C0000-00000000FFFFFFFF 800000000000000E > > > 0000000000000008* > > > NonExist 0000000100000000-0000FFFFFFFFFFFF 0000000000000000 > > > 0000000000000000 > > > > > > Step4 : Run the 'memmap' command. As we can see that entry is still > present. > > > Shell> memmap > > > Type Start End # Pages Attribu= tes > > > Available 00000000A0000000-00000000DFFFFFFF 0000000000040000 > > > 000000000000000E Available 00000000E01C0000-00000000E53C0FFF > > > 0000000000005201 000000000000000E > > > BS_Data 00000000E53C1000-00000000E5D99FFF 00000000000009D9 > > > 000000000000000E > > > ... > > > Available 0000008080000000-00000083FFFFFFFF 0000000000380000 > > > 000000000000000E > > > ... > > > _______________________________________________ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= l > > > is > > > ts.01 > > > .org%2Fmailman%2Flistinfo%2Fedk2- > > > > > > devel&data=3D02%7C01%7Cwasim.khan%40nxp.com%7C2be1d44f45084e831b92 > > > > > > 08d5542c1b7f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636507 > > > > > > 470804351379&sdata=3DB4v0K9MGZEWiSNYinRtWPGB%2F85biiU5iqpHmAE3YxsQ > > > %3D&reserved=3D0 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flist= s.01 > .org%2Fmailman%2Flistinfo%2Fedk2- > devel&data=3D02%7C01%7Cwasim.khan%40nxp.com%7Cd45b6709b297491dba9b > 08d5569e20f7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636510 > 159548814134&sdata=3D0evsd87geFVyGlX0rnzyLOXnIVrt4vbcLRgEQaZwWZw%3D > &reserved=3D0