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 B91142095DCA4 for ; Mon, 28 Aug 2017 10:33:26 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B54A4C057FAF; Mon, 28 Aug 2017 17:36:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B54A4C057FAF Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-67.phx2.redhat.com [10.3.116.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 27A7A18B84; Mon, 28 Aug 2017 17:36:03 +0000 (UTC) To: Andrew Fish Cc: edk2-devel-01 , Mike Kinney , "Gao, Liming" , Ard Biesheuvel , "Shi, Steven" References: <1714bf60-83a1-ce07-1d71-ac729d8e9dc8@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B57604E@shsmsx102.ccr.corp.intel.com> <37998be6-89f9-23a7-b1f5-a4527651d708@redhat.com> <06C8AB66E78EE34A949939824ABE2B313B57610E@shsmsx102.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <9c9632e3-2369-70d0-23ac-a5dcf278fec9@redhat.com> Date: Mon, 28 Aug 2017 19:36:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 28 Aug 2017 17:36:05 +0000 (UTC) Subject: Re: "practical" memory allocation limit? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:33:27 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/28/17 18:23, Andrew Fish wrote: > For X64 (x86-64) systems it is common for PEI to run in 32-bit mode > with paging disabled. This means the DXE Core gets loaded under 4GB > and and the HOBs and such are < 4GB. So having the initial memory map > < 4GB helps with preventing fragmentation. Hmm OK. That makes sense, thanks. > > There is also architectural cruft on x86. Historically some of the PCI > devices did not support DMA > 4GB and the system needed memory under > for DMA buffers. The other problem is processor mode transitions as > real mode code needs to be < 1MB and 32-bit protected mode needs to be > under 4GB. To get into the 64-bit long mode you start in real mode, > transition to protected mode, and then enter long mode. Even in 2017 > there are still real mode entry points required for x86, mainly the > reset vector, and IPI for the AP (how you wake up the other CPUs even > in the OS). If you are using a CSM and need to get into real mode I > think the thunk code assumes it runs < 4G (at least it did a long time > ago). > > Not to mention just general cruft in the code that has assumptions > about running < 4G (things like AsmThunk16(), CPU drivers etc.). Right, I've seen several examples for this in edk2; I just didn't understand why the "normal" stuff would get allocated by default under 4G. Mitigating fragmentation explains it though, thanks! >> On Aug 28, 2017, at 8:31 AM, Shi, Steven >> wrote: >> >> OK, got it. Thanks. (Um... looks like your email was technically in response to Steven's... but I got only yours (thus far), not Steven's.) >> For the why the 64bits DXE usually prefer allocations below 4GB, >> there is a good white paper elaborate the memory service >> initialization flows and can explain the reason. Please see the page >> 23 in below white paper (I have mark the answer in red). >> >> https://github.com/tianocore-docs/Docs/blob/master/White_Papers/A_Tour_Beyond_BIOS_Securiy_Enhancement_to_Mitigate_Buffer_Overflow_in_UEFI.pdf >> >> Heap Management in EDK II >> In UEFI, the DxeCore maintains the heap usage. The UEFI driver or >> application may call AllocatePages/FreePages/AllocatePool/FreePool to >> allocate or free the resource, or call GetMemoryMap() to review all >> of the memory usage. >> [Heap Initialization] >> When DxeIpl transfers control to the DxeCore, all of the resource >> information is reported in a Hand-off-Block (HOB) [PI] list. The >> DxeCore constructs the heap based upon the HOB information. See >> figure 4-2 Heap Initialization. >> 1) The DxeCore needs to find one region to serve as the initial >> memory in CoreInitializeMemoryServices() >> (https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Gcd/Gcd.c). >> The function is responsible for priming the memory map so that memory >> allocations and resource allocations can be made. If the memory >> region described by the PHIT HOB is big enough to hold BIN and >> minimum initial memory, this memory region is used as highest >> priority. It can make the memory BIN allocation to be at the same >> memory region with PHIT that has better compatibility to avoid memory >> fragmentation. Usually the BIN size is already considered by platform >> PEIM when the platform PEIM calls InstallPeiMemory() to PEI core. The top-posting got even more confusing here (I honestly can't tell who quoted this from the whitepaper), but it answers my question. To whomever I have to thank for it: thank you. :) Laszlo