From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 960621A1EE5 for ; Thu, 15 Sep 2016 02:01:48 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1A8114E4C3; Thu, 15 Sep 2016 09:01:48 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-94.phx2.redhat.com [10.3.116.94]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8F91k6s022663; Thu, 15 Sep 2016 05:01:47 -0400 To: Sakar Arora References: From: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Ard Biesheuvel Message-ID: Date: Thu, 15 Sep 2016 11:01:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 15 Sep 2016 09:01:48 +0000 (UTC) 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: Thu, 15 Sep 2016 09:01:48 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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? :)) Thanks Laszlo