From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 5CAE681C8D for ; Wed, 14 Dec 2016 20:55:44 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 14 Dec 2016 20:55:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,350,1477983600"; d="scan'208";a="18336885" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga002.jf.intel.com with ESMTP; 14 Dec 2016 20:55:43 -0800 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 14 Dec 2016 20:55:43 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 14 Dec 2016 20:55:42 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.9]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.235]) with mapi id 14.03.0248.002; Thu, 15 Dec 2016 12:55:41 +0800 From: "Gao, Liming" To: Michael Zimmermann , Ard Biesheuvel CC: "edk2-devel@lists.01.org" , "Gao, Liming" Thread-Topic: [edk2] correct way to reserve memory from PrePi? Thread-Index: AQHSVfPcmMcPLvb4BEO8+6LLeza/c6EHB0+AgAAtrQCAAToTIA== Date: Thu, 15 Dec 2016 04:55:40 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6A55EE@SHSMSX104.ccr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: correct way to reserve memory from PrePi? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 04:55:44 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael: I understand your usage that BuildResourceDescriptorHob adds system memor= y range, BuildMemoryAllocationHob allocate the full memory range as reserve= d memory. Then, you expect they can be shown in EFI memory map. Right?=20 BuildResourceDescriptorHob() with (start,size) 0x80000000,0x80000000, the= n BuildMemoryAllocationHob() with (start,size) 0x80000000,0x80000000. It do= esn't work.=20 Two BuildResourceDescriptorHob() with (start,size) 0x80000000,0x40000000 = and 0xc0000000,0x40000000, then two BuildMemoryAllocationHob(). It does wor= k. Right? Thanks Liming > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Michael Zimmermann > Sent: Thursday, December 15, 2016 1:57 AM > To: Ard Biesheuvel > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] correct way to reserve memory from PrePi? >=20 > I've enabled GCD debugging and apparently it doesn't accept the allocatio= n: > GCD:AllocateMemorySpace(Base=3D0000000090000000,Length=3D0000000010000 > 000) > GcdAllocateType =3D AtAddress > GcdMemoryType =3D SystemMem > Alignment =3D 0000000000000001 > ImageHandle =3D FDE28F90 > DeviceHandle =3D 0 > CoreAllocateSpaceCheckEntry:982 handle=3DFDE28F90 > CoreAllocateSpace:1130 > Status =3D Not Found > GCDMemType Range Capabilities > Attributes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=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-000000007FFFFFFF 0000000000000000 > 0000000000000000 > SystemMem 0000000080000000-00000000FDFFFFFF 800000000000000E > 0000000000000000* > NonExist 00000000FE000000-00000000FE3FFFFF 0000000000000000 > 0000000000000000 > SystemMem 00000000FE400000-00000000FFFE5FFF 800000000000000E > 0000000000000000 > SystemMem 00000000FFFE6000-00000000FFFEEFFF 800000000000000E > 0000000000000000* > SystemMem 00000000FFFEF000-00000000FFFFFFFF 800000000000000E > 0000000000000000 >=20 >=20 > It fails in this line: > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe > /Gcd/Gcd.c#L982 > In this example I've used(start,size) 0x80000000,0x80000000 for the > resource descriptors. > If I use 0x80000000,0x40000000 and 0xc0000000,0x40000000 everything > works just fine. >=20 > Thanks > Michael >=20 > On Wed, Dec 14, 2016 at 4:13 PM, Michael Zimmermann > wrote: > > As far as I know the proper way is to create resource descriptors > > using BuildResourceDescriptorHob and then allocate reserved areas > > using BuildMemoryAllocationHob. This way I don't have any overlapping > > descriptors - I just allocated some memory very early. > > > > I ran many tests and it looks like all calls to > > BuildMemoryAllocationHob get ignored if my dram hobs look like this: > > 0x00000000 - 0x40000000 > > > > If I split this range into two Hob's like this everything seems to > > work just fine: > > 0x00000000 - 0x20000000 > > 0x20000000 - 0x20000000 > > > > I took a look at other platforms like Juno and they add big dram Hob's > > (2GB and 6GB) too so why is this a problem? > > > > Thanks > > Michael > > > > On Wed, Dec 14, 2016 at 11:21 AM, Ard Biesheuvel > > wrote: > >> On 14 December 2016 at 10:02, Michael Zimmermann > >> wrote: > >>> I tried both BuildResourceDescriptorHob and BuildMemoryAllocationHob > >>> but apparently they don't have any effect. > >>> When I look at the output of the shell's memmap command there aren't > >>> any reserved/unavailable pages. > >>> > >>> Furthermore, when using AllocatePages with one of the physical > >>> addresses which I've reserved it succeeds which means that it's not > >>> just a problem of how the memmap command works. > >>> > >>> Am I doing something wrong or is this a bug? > >>> > >> > >> I think you need to ensure that they don't overlap existing resource > >> descriptors: if you declare a region as reserved, you should not > >> declare it as memory first > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel