From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 C146C2095DCA4 for ; Mon, 28 Aug 2017 09:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1503937439; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NPPzM84zkbbPvC/6+oGiqerI/dzG+ceKuMBHzBHffds=; b=rA5CnEtVkYzuR76z9I11iBF+q0ULzw/G91KKa1QtG6YVrd7yzotCnIuSz44fQFK6 a4j29GbQaJD5a5UJMcruWewaQYmO8t38aW4rO/XQiOoPf5eC1q+vRw8eqlIWBF8S 4j+81G87mYZaR/+Exy70xR1WC/L2KbD4AzEcgQVLTncsRQN/1+9KtPDXMw8xuY97 kYwjQM+rzIDxwSD9ZyuH+bUMgb6aNGTRWQU4gimGZYGscl+xxmV+HLPqNpThe3sQ 3uAWMNyWHD56kx3UkIYQyQ8qU76BtI/rwg5KzGzXUYIBWoj4vO0S2kKw/5K3Jd1n 3nbf0qEKaqdF8btQ50VdmQ==; Received: from relay27.apple.com (relay27.apple.com [17.171.128.108]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 0A.26.25405.F9344A95; Mon, 28 Aug 2017 09:23:59 -0700 (PDT) X-AuditID: 11ab0218-263ff7000000633d-12-59a4439fcf61 Received: from ma1-mmpp-sz07.apple.com (ma1-mmpp-sz07.apple.com [17.171.128.149]) by relay27.apple.com (Apple SCV relay) with SMTP id F3.9F.03167.F9344A95; Mon, 28 Aug 2017 09:23:59 -0700 (PDT) MIME-version: 1.0 Received: from [17.234.215.205] by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OVE00GQ1LJWMB90@ma1-mmpp-sz07.apple.com>; Mon, 28 Aug 2017 09:23:59 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: <06C8AB66E78EE34A949939824ABE2B313B57610E@shsmsx102.ccr.corp.intel.com> Date: Mon, 28 Aug 2017 09:23:58 -0700 Cc: edk2-devel-01 , Mike Kinney , "Gao, Liming" , Ard Biesheuvel , "Shi, Steven" Message-id: 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> To: Laszlo Ersek X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUiuLohR3e+85JIg9MnxS3+f9jNaLHn0FFm i2XHdrBYrLi3gd2io+Mfk8WP/n4WBzaPxXteMnncubaHzaN79j8Wj/f7rrIFsERx2aSk5mSW pRbp2yVwZcxacoutYJdpxavpP5gbGC9odjFyckgImEjcnf2dtYuRi0NIYD2TxMvt11hhEofP 72aBSBxmlNj2fBUbSIJXQFDix+R7QAkODmYBeYmD52VBwswCWhLfH7VC1X9jlHix7T47SEJY QFzi3ZlNzBC2hcSXzc1gc9gElCVWzP8AVsMpECbxtGcnE4jNIqAqsXLdJWaQQcwCVxkl9r55 ygSx2Ebi5p5OqA2tTBKf2k6CTRIRUJGYPeEBE8TZshK3ZkN0SwhsYJO43biEfQKj8Cwkl89C uHwWkssXMDKvYhTOTczM0c3MMzLRSywoyEnVS87P3cQIjg4miR2MX14bHmIU4GBU4uFdYb0k Uog1say4MvcQozQHi5I476vTCyKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLaVeD34KfON X+zpTZ2Xmyct+XmyfqLykf03DFZvFIvesaz7mPXxL3rc6//P+PU95HNFtU2SWQaz9MW5kmeU V9Zcs71pEHtuIXv+7XXqHT6zlc++O+TzuLH6qYhBe6TwLKaMl7sS3VL7OtWr3+mU34uLDz65 JWfxpbNHk2VsPt45LiMaFVtmnaHEUpyRaKjFXFScCABdBvNwbwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUiuLphqu585yWRBuvmCVr8/7Cb0WLPoaPM FsuO7WCxWHFvA7tFR8c/Josf/f0sDmwei/e8ZPK4c20Pm0f37H8sHu/3XWULYInisklJzcks Sy3St0vgypi15BZbwS7TilfTfzA3MF7Q7GLk5JAQMJE4fH43SxcjF4eQwGFGiW3PV7GBJHgF BCV+TL4HlODgYBaQlzh4XhYkzCygJfH9UStU/TdGiRfb7rODJIQFxCXendnEDGFbSHzZ3Aw2 h01AWWLF/A9gNZwCYRJPe3YygdgsAqoSK9ddYgYZxCxwlVFi75unTBCLbSRu7umE2tDKJPGp 7STYJBEBFYnZEx4wQZwtK3Fr9iXmCYwCs5AcOwvh2FlIjl3AyLyKUbAoNSex0shcL7GgICdV Lzk/dxMjJJhzdjDeuWl2iFGAg1GJh3eF9ZJIIdbEsuLK3EOMEhzMSiK8L52AQrwpiZVVqUX5 8UWlOanFhxilOViUxHm9j82JFBJITyxJzU5NLUgtgskycXBKNTBK6jQeDdi/42eiYaqlxtkX Nwz+akglGP+9st6IK/5r1J3eKlub4pP71/msWXtugduUSUct3K88Edgys9Npy4x2lmIBDzNV xzVPfKS3eB2wvVdx+52StmSxNp//3a0Mj/32aMy4kZ1fu8BI/f5DJcZ3bcsXGrWGc+f87rku OXeCscEX6/Nhs9YrsRRnJBpqMRcVJwIAHXFO/mICAAA= 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 16:21:21 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII 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. 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.). Thanks, Andrew Fish > On Aug 28, 2017, at 8:31 AM, Shi, Steven wrote: > > OK, got it. Thanks. > > > > 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/G > cd.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. > > > > > > > > > Steven Shi > > Intel\SSG\STO\UEFI Firmware > > > > Tel: +86 021-61166522 > > iNet: 821-6522 > > > > > >> -----Original Message----- > >> From: Laszlo Ersek [mailto:lersek@redhat.com] > >> Sent: Monday, August 28, 2017 10:40 PM > >> To: Shi, Steven ; edk2-devel-01 >> devel@lists.01.org> > >> Cc: Kinney, Michael D ; Gao, Liming > >> ; Ard Biesheuvel > >> Subject: Re: [edk2] "practical" memory allocation limit? > >> > >> On 08/28/17 16:25, Shi, Steven wrote: > >>> Hi Laszlo, > >>> > >>> I happen to have a question about how to correctly get the system memory > >> size on Qemu. > >>> > >>> In the QemuInitializeRam() of OvmfPkg\PlatformPei\MemDetect.c, I add > >> debug info as below to trace the GetSystemMemorySizeBelow4gb() and > >> GetSystemMemorySizeAbove4gb() output. But the output results seems not > >> right if my input memory size > 4GB. See my commands and trace outputs in > >> below. > >>> > >>> > >>> > >>> MemDetect.c Line 602: > >>> > >>> // > >>> > >>> // Determine total memory size available > >>> > >>> // > >>> > >>> LowerMemorySize = GetSystemMemorySizeBelow4gb (); > >>> > >>> UpperMemorySize = GetSystemMemorySizeAbove4gb (); > >>> > >>> DEBUG ((EFI_D_INFO, "LowerMemorySize= 0x%x\n", LowerMemorySize)); > >>> > >>> DEBUG ((EFI_D_INFO, "UpperMemorySize= 0x%x\n", UpperMemorySize)); > >>> > >>> > >>> > >>> My test commands and trace outputs: > >>> > >>> $ /opt/qemu/bin/qemu-system-x86_64 -m 5120 -enable-kvm -hda > >> /home/jshi19/workspace/simics5-project/images/luv- > >> v2.1_diskboot_gpt_x86_64_.img -machine pc-q35-2.9 -bios OVMF.fd -serial > >> file:serial.log > >>> > >>> LowerMemorySize= 0x80000000 //2GB, but should not it be 4GB? > >>> > >>> UpperMemorySize= 0xC0000000 //3GB, but should not it be 1GB? > >> > >> No, this is correct; the values returned are system memory *amounts*. > >> (On the QEMU command line, the "-m" switch says how much system > >> memory > >> you have, not the highest address in system memory.) > >> > >> In the 4GB address space, you don't have *just* system memory, you have > >> a whole bunch of MMIO too. (Most of that is used for 32-bit MMIO PCI BAR > >> allocation, some is used for the pflash chip range, LAPICs, etc.) On Q35 > >> you also have 256MB assigned to the MMCONFIG / ECAM area (which > >> provides > >> direct MMIO access to PCI config space for PCI 256 buses). > >> > >> The physical memory map also depends on the board model; on i440fx, the > >> 32-bit system memory can go up to 3GB, while on Q35, it only goes up to > >> 2GB. > >> > >> So, if you pass 5GB to a Q35 machine, 2GB of that are placed in the > >> address space at [0, 2G), and the other 3GB are placed in the address > >> space at [4G, 7G). > >> > >>> $ /opt/qemu/bin/qemu-system-x86_64 -m 6144 -enable-kvm -hda > >> /home/jshi19/workspace/simics5-project/images/luv- > >> v2.1_diskboot_gpt_x86_64_.img -machine pc-q35-2.9 -bios OVMF.fd -serial > >> file:serial.log > >>> > >>> LowerMemorySize= 0x80000000 //2GB, but should not it be 4GB? > >>> > >>> UpperMemorySize= 0x0 // 0GB, but should not it be 2GB? > >> > >> With 6G DRAM, 2G go low, and 4G go high. > >> > >> (Your output is misleading because you used the %x format specifier in > >> your debug message -- %Lx would be correct, for printing a UINT64 value.) > >> > >> Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel