From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0613.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::613]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 56FD01A1E6C for ; Wed, 21 Sep 2016 02:10:41 -0700 (PDT) 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=t7ViOHQVrda1MxDlfehSu7jU7K157VO4B2bYluTAHMA=; b=PGsxZky9kt+ebH/jYGn6Bk0D3vlWjU9LhusToUG6JOIAVteD9f0cYNn5FkpQRhwKahCwk9BkURu5z9sDG4XCVPqi5EtHtgks13ZjTEDjRkh4H0KQgMkyIoLOXQknkPisEN3mz/pxidfFI8ZUQN2nfizMyqwpaXWTBYUR8Xa+E0I= Received: from AM4PR0401MB2289.eurprd04.prod.outlook.com (10.165.45.12) by VI1PR04MB2174.eurprd04.prod.outlook.com (10.166.43.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.2; Wed, 21 Sep 2016 09:10:38 +0000 Received: from AM4PR0401MB2289.eurprd04.prod.outlook.com ([10.165.45.12]) by AM4PR0401MB2289.eurprd04.prod.outlook.com ([10.165.45.12]) with mapi id 15.01.0639.005; Wed, 21 Sep 2016 09:10:38 +0000 From: Bhupesh Sharma To: Ard Biesheuvel , Laszlo Ersek CC: "edk2-devel@lists.01.org" , Sakar Arora Thread-Topic: [edk2] Exporting discontiguous System Memory to EFI STUB Thread-Index: AQHSDxksWkz+miXOZ0idgVUkRmEEj6B6PL3sgAAEogCAACm4gIAJGO1Q Date: Wed, 21 Sep 2016 09:10:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bhupesh.sharma@nxp.com; x-originating-ip: [192.88.169.1] x-ms-office365-filtering-correlation-id: 2f4fdd50-3872-46b4-5632-08d3e1ff27a2 x-microsoft-exchange-diagnostics: 1; VI1PR04MB2174; 6:avXWacTUBIngBZnl+BOmKIeEX+uxQRle1bUmu/kVEt64ycEcjKDHIebvb0JwC029PZSW0c52h/17kKr3jHObU2cgK6EZ4v70usaQfMLQ4Afsbu72G2e3UDP/rYH00TKcB7q80uSwTH3RZizoWtayg6UAupI6CN7TXpojISHxsySzyKGQ+1fFoXE0L1kZktuahu2kCcyyRwt/1c8pZYrL2yKiEfFx6ooHJVFrrBoSRp8C3ITMY7kgg++qeFcDirDW7CoSSISY0AsZOoyVrNMHbLYLkO09wQh/QpI2dLeFcd5fp6V+9DbXS3DGsUrRu9y1yUm5WE5R+cWUerqbLs3alg==; 5:i4f/QLO9NZGsgxIeFA1y2LskjCSQ/rZvXsAWzdYiYckoYe4ENu7iCFuKc2QZa6uf4qwJOO6bNVeBBos96e/UAo/trUo6830TgOY1hwz/s5gMg8m60uvQUo3s91gwRYTVIdxpa5NaZYsvcFzQ3VR0Ug==; 24:CcRq5iA2YslCnxnZYxjECs1Ap9tBaoPS+/AEzadceNY03B3RAQBnPnQSJCJ7ojSGXCWu4noYOzizy+WMLU3RvDurhIJQvuDZD94brcBnl3Y=; 7:vEV9ic2fqRYUVsHDINWewV03fAiuwJoNovlP+G8kpKrsnmG9wzsW+ave4Dr21QPlZIg/RynP6Yo68rWEgehZjDg+M/eYXGZtiMmYi6pVh2lZkF+aocuHrUJ7H09A8G2RSvxVxoT1UI6tMzTUMnVhGAUAf052pZeZ/9DaHaFESKAQD6nH6X75LDn501rMEn081HzO2k9bkpkUVcKOICBDL59rqXc3yH6r6z5Xr09DAjtWBy9fwZN8WQxWy9jbPEnyukTZS1NIbDy8jIlhq/5qT1Q5SzanKb3B36k/5AHVVpn5n4mTIqrCx5akDDVpFvxN x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR04MB2174; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(258649278758335); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:VI1PR04MB2174; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB2174; x-forefront-prvs: 007271867D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(189002)(377454003)(199003)(10400500002)(92566002)(66066001)(87936001)(33656002)(189998001)(3660700001)(122556002)(11100500001)(9686002)(76576001)(68736007)(3280700002)(74316002)(15975445007)(50986999)(8936002)(106116001)(5660300001)(54356999)(102836003)(3846002)(6116002)(586003)(2906002)(4326007)(76176999)(105586002)(106356001)(7736002)(305945005)(19580395003)(101416001)(97736004)(7846002)(81166006)(81156014)(7696004)(77096005)(5001770100001)(93886004)(5002640100001)(2900100001)(8676002)(19580405001)(2950100001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR04MB2174; H:AM4PR0401MB2289.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2016 09:10:38.5380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB2174 Subject: Re: Exporting discontiguous System Memory to EFI STUB 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: Wed, 21 Sep 2016 09:10:41 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Ard, Laszlo. See replies in-line: > From: Ard Biesheuvel > Sent: Thursday, September 15, 2016 5:01 PM >=20 > On 15 September 2016 at 10:01, Laszlo Ersek wrote: > > On 09/15/16 10:45, Sakar Arora wrote: > >> Hi > >> > >> This is in aarch64 UEFI context. > >> > >> The efi stub code ignores any memory nodes in the device tree. It > >> only relies on the UEFI memory map for memory info. > >> > >> In such a scenario, how can one export discontiguous regions of > >> system memory to the efi stub? There seems to be only one way to > >> inform UEFI about system memory, via PcdSystemMemoryBase. > >> > >> Looking at the latest Arm Juno code, it seems like building a memory > >> resource descriptor hob, for the extra memory region, does the > trick. > >> Would that be the best way to go? > >> > >> Suggestions please. > > > > There are two ways. > > > > First, in the PEI phase, you can produce memory resource descriptor > > HOBs that will describe system memory areas. When the DXE core > starts, > > it will convert the suitable HOBs to EfiGcdMemoryTypeSystemMemory > > memory space. During DXE and BDS, boot/runtime code/data allocations > > will be satisfied from these. Then the UEFI memmap will reflect those > > allocations, and the system memory left unused, to the EFI stub. > > > > Second, you can add EfiGcdMemoryTypeSystemMemory memory space during > > and after the DXE phase, explicitly, using the DXE services. (IIRC, > > the PI spec says that memory space added this way may be picked by > the > > UEFI memory allocation system immediately; IOW, it may immediately > > become available to the pool and page allocation boot serivces, to > > allocate from. IIRC, in edk2 this actually happens.) The rest is the > > same as above, wrt. the UEFI memmap. > > > > You can see an example for the second method under > > "ArmVirtPkg/HighMemDxe". I think it might be particularly close to > > your use case, as it practically translates the memory nodes found in > > QEMU's > > (copied) DTB to EfiGcdMemoryTypeSystemMemory memory space. > > > > (Ard, when do you plan to port this driver to FDT_CLIENT_PROTOCOL? > :)) > > >=20 > Any day now :-) >=20 > But seriously, I think this is orthogonal to the question, since I > don't expect that this platform uses DTB to describe the platform *to > UEFI*, and it would not run any of the runtime DT probing code. >=20 > So in this particular case, it is simply a matter of adding the > additional memory at any point during the execution of UEFI that is > convenient, by using one of the two methods you describe. >=20 Yes, this platform, which has been extensively discussion on Linux mailing-= lists as well for discontiguous memory regions and their support in Linux (see [1= ]), doesn't use DTB to describe the platform *to UEFI*. However I have one generic question. At the moment we seem to use the PcdSy= stemMemoryBase and PcdSystemMemorySize PCDs to convey to the PEI and DXE phases about the = UEFI system memory limits.=20 How can we represent two discontiguous DDR regions in UEFI and make the EDK2 code base use both - to create MMU mappings from? [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/435607.= html Regards, Bhupesh