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 7C0861A1EDF for ; Wed, 21 Sep 2016 04:32:52 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 096C2C04B925; Wed, 21 Sep 2016 11:32:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-25.phx2.redhat.com [10.3.116.25]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8LBWotP006281; Wed, 21 Sep 2016 07:32:50 -0400 To: Ard Biesheuvel References: <4d4fe42c-0aeb-698b-9da5-63d8c215a160@redhat.com> Cc: Bhupesh Sharma , "edk2-devel@lists.01.org" , Sakar Arora From: Laszlo Ersek Message-ID: <8af1b2c5-a748-3635-6f67-1bcf685d5bec@redhat.com> Date: Wed, 21 Sep 2016 13:32:49 +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.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 21 Sep 2016 11:32:52 +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: Wed, 21 Sep 2016 11:32:52 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 09/21/16 13:20, Ard Biesheuvel wrote: > On 21 September 2016 at 12:17, Laszlo Ersek wrote: >> On 09/21/16 11:10, Bhupesh Sharma wrote: >>> Thanks Ard, Laszlo. >>> >>> See replies in-line: >>> >>>> From: Ard Biesheuvel >>>> Sent: Thursday, September 15, 2016 5:01 PM >>>> >>>> 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? >>>> :)) >>>>> >>>> >>>> Any day now :-) >>>> >>>> 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. >>>> >>>> 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. >>>> >>> >>> 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 PcdSystemMemoryBase >>> and PcdSystemMemorySize PCDs to convey to the PEI and DXE phases about the UEFI system >>> memory limits. >> >> No, that's incorrect. These PCDs don't capture the full picture about >> the "UEFI system memory limits". They just describe one initial memory >> range; the one that will serve as the permanent PEI RAM. (In the PEI >> phase, one of the PEIMs discovers and installs the "permanent PEI RAM", >> which is one contiguous range, to be used by the rest of the PEI phase. >> A bit later, the PEI core, the PEIMs, the HOBs etc (IIRC) are migrated >> from the temporary PEI RAM to this "installed" permanent PEI RAM.) >> >> However, starting with the DXE phase, disjoint ranges of RAM are >> supported; they can be installed by either using the appropriate DXE >> services within DXE, or by producing appropriate HOBs still in PEI. >> >> >>> >>> How can we represent two discontiguous DDR regions in UEFI and make >>> the EDK2 code base use both - to create MMU mappings from? >> >> As I said, by producing the right HOBs in PEI or by calling the right >> DXE services in DXE. The actual range locations (= the fields of the >> HOBs or the arguments to the DXE services) depend on your platform. >> >> Regarding the MMU: I don't know. I had always believed that the DXE >> services should cover the MMU setup transparently, when new system >> memory ranges are added -- as long as they exist within the address >> space pre-announced by the CPU HOB --, but I do recall from another >> thread on the list that this wasn't the case on ARM. I don't know why. >> > > I recently fixed a problem in the MMU code where the maximum size of > the VA range which is programmed into the MMU registers was based on > the initial memory size, and adding memory (or MMIO) ranges later > would cause problems. > > WIth the latest EDK2, adding memory may be done at any time, and will > be reflected in the 1:1 mapping in the MMU Perfect, thank you! Laszlo