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 CDA6781D6A for ; Fri, 20 Jan 2017 08:38:17 -0800 (PST) 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 60F077FE8C; Fri, 20 Jan 2017 16:38:18 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-71.phx2.redhat.com [10.3.116.71]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0KGcHYC002123; Fri, 20 Jan 2017 11:38:17 -0500 To: Ard Biesheuvel References: From: Laszlo Ersek Cc: edk2-devel-01 Message-ID: <9fdd45fb-710c-cd62-d65e-fe541037a069@redhat.com> Date: Fri, 20 Jan 2017 17:38:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.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.27]); Fri, 20 Jan 2017 16:38:18 +0000 (UTC) Subject: Re: [QUESTION] reservation of pool allocations performed during PEI 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: Fri, 20 Jan 2017 16:38:17 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 01/20/17 17:05, Ard Biesheuvel wrote: > After a recent change to the AArch64 page table code, the root table > of the page tables is allocated using AllocatePool() rather than > AllocatePages() if its size is much smaller than a page. E.g., when > using 40 bits of translation, the root table only takes up 16 bytes > > However, what I have noticed is that pool allocations made during PEI > are listed as available memory in the EFI memory map (using memmap in > the UEFI Shell). Is this expected? Is it part of the contract that > AllocatePool() allocations are lost when entering DXE? Pool allocations in PEI are satisfied with HOBs (and therefore the pool allocation sizes are limited to ~64KB). In addition, soon after permanent PEI RAM is installed, objects from the temporary SEC/PEI heap are moved there (this is called "temporary RAM migration"). This includes the migration of the full HOB list, including those that were used to satisfy pool allocations prior to RAM migration. If you want to allocate memory in PEI that is to survive in-place into DXE and later, I can think of two ways: - Call AllocatePages. This will only work after permanent PEI RAM has been installed (so you might want to make the PEIM performing the call dependent on gEfiPeiMemoryDiscoveredPpiGuid, with a DEPEX). The allocation will be carved out of the permanent PEI RAM. - Allocate a region (a whole multiple of pages) outside of the permanent PEI RAM, but in a spot that will later on be backed by system memory (due to a system memory resource descriptor HOB produced in PEI, or due to a GCD memory space addition during DXE). The way to perform this kind of allocation is simply to produce a memory allocation HOB, covering the range in question. This works even before the installation of permanent PEI RAM. ... I hope I remembered most of this stuff right. Thanks Laszlo