From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 608851A1EF4 for ; Thu, 15 Sep 2016 04:31:07 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id o3so90242819ita.1 for ; Thu, 15 Sep 2016 04:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o8XbGul82mdQDze36YxPUMXl6qQugL9U23K2QOMTyAg=; b=Psw6Gbr0xDpAb+95I7teLTtnoQBK8HMPGl6alsde9w4wVS/W3CeFc0OWmyHP95o4x+ 1fvqV29Hbdgr4kFCrcagB83gKO+vo3l9vN/C+ou+dyPu+aHmVckS64zj1nUTLkEO7UX1 oaxQ+rb5rrj0dESjIV3PLncdV1cAPRyJls/Uc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o8XbGul82mdQDze36YxPUMXl6qQugL9U23K2QOMTyAg=; b=cyxkENbVZhkSs9KZija5OaypyZXP+JXB4F1dQJKXY65aXs9GG4fhNHghDiF6yfn250 cPzDU0dI36UmvJ7uYG+4/WDzNv7cbq1yhlBIUAAL788aeAeq/U4iARMvP8qOzOckIi6b YgQefBQVbG8DadXGQ9kYmjrPWxtE9z0tJc1mtGUlCKL94O8AKuPd5D2uIL5T/bIQFbjk G/+mJD9Ul5a/xUgokHiI4bBM4Fx7iq9huZWmH+izAOp7Do0NQDr+wkDfXGFjt/SLIRF2 BDRR7I3WcmIJ9IMW8JFtopil7WfswPBRE4h7URIOFi2spRIjynoj28bpRDFAoDwrEH4P KmPA== X-Gm-Message-State: AE9vXwO3w/Xs4iiNOs2bXo4dd5NKXPY/EogL9FePKz8X0NBkQAiSR7NWQWM3cRxsKJz8KWfgYGv+FR3XVcLedgaK X-Received: by 10.107.10.195 with SMTP id 64mr15476383iok.183.1473939066653; Thu, 15 Sep 2016 04:31:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Thu, 15 Sep 2016 04:31:05 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Thu, 15 Sep 2016 12:31:05 +0100 Message-ID: To: Laszlo Ersek Cc: Sakar Arora , "edk2-devel@lists.01.org" 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 11:31:07 -0000 Content-Type: text/plain; charset=UTF-8 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. Thanks, Ard.