From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=104.47.1.49; helo=eur01-ve1-obe.outbound.protection.outlook.com; envelope-from=wasim.khan@nxp.com; receiver=edk2-devel@lists.01.org Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0049.outbound.protection.outlook.com [104.47.1.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 10A132094561A for ; Mon, 8 Jan 2018 04:43:15 -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=zRVgI+pSCUeguPgQC3gvffBvUdvUpv5GyGZsmanPMSY=; b=fFwtqMgMH7lDHU67hBNCXkRgqEffrbaAlLTxI/h2IAZoP2eLT/y7zVS2MZJm/7c9fMfH10iI2csvjEGzAub6iTbqyrjt3edzh5Ci7wxJ2EBeYsPAR4onvWpvWtCy625lLSRtokThwZFldcggCDmUTvG/LDqZ49Phk4/1q6QSqZE= Received: from DB6PR0401MB2342.eurprd04.prod.outlook.com (10.168.54.155) by DB6PR0401MB2341.eurprd04.prod.outlook.com (10.168.54.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.8; Mon, 8 Jan 2018 12:48:21 +0000 Received: from DB6PR0401MB2342.eurprd04.prod.outlook.com ([fe80::fd7b:6470:427c:aea8]) by DB6PR0401MB2342.eurprd04.prod.outlook.com ([fe80::fd7b:6470:427c:aea8%17]) with mapi id 15.20.0366.011; Mon, 8 Jan 2018 12:48:21 +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/zdQAHS4DAAADWQ3gAAYAkIw Date: Mon, 8 Jan 2018 12:48:20 +0000 Message-ID: References: <0C09AFA07DD0434D9E2A0C6AEB0483103B9F8894@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B9F8CA8@shsmsx102.ccr.corp.intel.com> In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B9F8CA8@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; DB6PR0401MB2341; 7:hubnPyMNlLm3a6axf48ff+C0fdkHMGa6fDaAdpO9k0KtPmPpweAnOdxPe8eKM7I6eJXjYLpXPfo5KDdyMFp91tEs0JVkGorTTRc1f3IiWbJoSdM7zVmHB1hDn6W8Opoyz1awfWKYoDqzHzJEFSBIO/5kZVf/zufalOusoFRigHAjXLjq+5mJKAK/3/fZG/Px5ZElMs98nd82/NWthntZ7+PGS2u8mOT3f3DxITGHSlnUqpj2U41zt2S8/RDS3NVT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d458cfad-abaf-44d8-64ac-08d556961936 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(48565401081)(2017052603307)(7153060)(7193020); SRVR:DB6PR0401MB2341; x-ms-traffictypediagnostic: DB6PR0401MB2341: 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)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DB6PR0401MB2341; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR0401MB2341; x-forefront-prvs: 054642504A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(39860400002)(376002)(346002)(366004)(13464003)(189003)(53754006)(199004)(57704003)(81156014)(575784001)(59450400001)(7736002)(68736007)(74316002)(305945005)(6506007)(45080400002)(76176011)(102836004)(4326008)(86362001)(8676002)(53546011)(478600001)(110136005)(966005)(2900100001)(14454004)(316002)(3280700002)(66066001)(5250100002)(99286004)(345774005)(8936002)(2501003)(7696005)(105586002)(25786009)(106356001)(6306002)(229853002)(9686003)(81166006)(5660300001)(33656002)(3660700001)(6116002)(6436002)(53936002)(55016002)(97736004)(2950100002)(6246003)(3846002)(2906002)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0401MB2341; H:DB6PR0401MB2342.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: XB1aB41ZVPBuZ3GliGdLP8wQoyMNmuiY9/FfwK/IQ2w2YCfEBNLHo2vb77eKu4YaWoZ73QQGGECfrldbHN6cuw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: d458cfad-abaf-44d8-64ac-08d556961936 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2018 12:48:20.9621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0401MB2341 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: Mon, 08 Jan 2018 12:43:17 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Star, I agree with you that 'gDS->AddMemorySpace' should always pass, but if thes= e functions are made to=20 return the Status, we should ideally check the Status and take necessary ac= tions upon failure. After going through the code, if a memory space for EfiGcdMemoryTypeSystemM= emory (or EfiGcdMemoryTypeMoreReliable) is=20 added then memory range is automatically allocated for use by the UEFI mem= ory services by adding a memory descriptor to gMemoryMap . But when we call 'gDS->FreeMemorySpace' and ''gDS->RemoveMemorySpace' , mem= ory space is only removed from GCD map and it is not=20 removed from UEFI Services map. So ideally while when a call to gDS->AddMemorySpace (for memory type EfiGcd= MemoryTypeSystemMemory)=20 automatically allocates it for use by UEFI memory services. It should also = free the memory when 'gDS->FreeMemorySpace' call is made. I have opened a ticket for this issue (https://bugzilla.tianocore.org/show_= bug.cgi?id=3D841) . Regards, Wasim > -----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 FreeMemorySp= ace > and RemoveMemorySpace >=20 > Hi Wasim, >=20 > Got the point. >=20 > 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() wi= th > 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. >=20 >=20 >=20 > 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 FreeMemorySp= ace > and RemoveMemorySpace >=20 > Hi Star, >=20 > Thank you for your reply. >=20 > 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 sp= ace as > EfiGcdMemoryTypeSystemMemory only. >=20 > > What is the usage that the memory space needs to be added first and rem= oved > later? > No specific use case, I am checking the status of 'gDS->AddMemorySpace' a= nd > 'gDS->SetMemorySpaceAttributes', if any of these calls fails, I want to r= emove > the added memory space. Ideally it should work. >=20 >=20 >=20 > Regards, > Wasim >=20 >=20 >=20 > > -----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 ( > > EfiGcdMemoryTypeSystemMemor= y, > > FixedPcdGet64(PcdSystemMemo= ryExBase), > > SystemMemoryExSize, > > EFI_MEMORY_WC | EFI_MEMORY_= 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 Attribute= s > > =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 Attribute= s > > =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 Attribute= s > > =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 Attribute= s > > =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 pre= sent. > > Shell> memmap > > Type Start End # Pages Attribute= s > > 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%2Fli= s > > 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