From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=210.71.195.41; helo=out02.hibox.biz; envelope-from=tim.lewis@insyde.com; receiver=edk2-devel@lists.01.org Received: from out02.hibox.biz (out01.hibox.biz [210.71.195.41]) (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 96113207E635A for ; Mon, 14 May 2018 18:18:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AJAgAnNfpa/w00GKxZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDQ2F7KIxWjg0xAV2CFpMUCxgLCAGEOgQCAoMQIjgUAQIBAQE?= =?us-ascii?q?BAQECbBwMhSgBAQEBAgEBAQYCHhIcCAwECwUHAQMCBgMNAQMEAQEvGQ4BERYIA?= =?us-ascii?q?gQBEgsFgxWBdwgPrWMxGgKIL4IiBYl5P4EPgl0ugxEBBIF+JoUNAox7izsHAgK?= =?us-ascii?q?BZ4N+hQ6DXIE2g2WCUIUEiVWHDoElMyGBUnBQgkM/ilGFXh8wgQ0IDAGPZgEB?= X-IronPort-AV: E=Sophos;i="5.49,402,1520870400"; d="scan'208";a="4733264" Received: from unknown (HELO hb3-BKT203.hibox.biz) ([172.24.52.13]) by out02.hibox.biz with ESMTP; 15 May 2018 09:18:25 +0800 Received: from unknown (HELO hb3-BKT101.hibox.biz) ([172.24.51.11]) by hb3-BKT203.hibox.biz with ESMTP; 15 May 2018 09:18:26 +0800 Received: from unknown (HELO hb3-IN03.hibox.biz) ([172.24.12.13]) by hb3-BKT101.hibox.biz with ESMTP; 15 May 2018 09:18:25 +0800 X-Remote-IP: 73.116.1.175 X-Remote-Host: c-73-116-1-175.hsd1.ca.comcast.net X-SBRS: -10.0 X-MID: 12450560 X-Auth-ID: tim.lewis@insyde.com X-EnvelopeFrom: tim.lewis@insyde.com hiBox-Sender: 1 Received: from c-73-116-1-175.hsd1.ca.comcast.net (HELO DESKTOPAVHFBJF) ([73.116.1.175]) by hb3-IN03.hibox.biz with ESMTP/TLS/AES256-SHA; 15 May 2018 09:18:24 +0800 From: "Tim Lewis" To: "'Bill Paul'" , Cc: "'Neri, Ricardo'" References: <201805141812.37378.wpaul@windriver.com> In-Reply-To: <201805141812.37378.wpaul@windriver.com> Date: Mon, 14 May 2018 18:18:18 -0700 Message-ID: <00b901d3ebea$9d350a90$d79f1fb0$@insyde.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI5P4A8sr9UkMStmBGiWmS+XQwKMAJNeThDo1LqLkA= Subject: Re: Query regarding hole in EFI Memory Map X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 01:18:42 -0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us And now you see it again with 64-bit machines, where the flash and PCI config space (and MMIO) appear below 4GB, but there is DRAM above and below 4GB. Tim -----Original Message----- From: edk2-devel On Behalf Of Bill Paul Sent: Monday, May 14, 2018 6:13 PM To: edk2-devel@lists.01.org Cc: Neri, Ricardo Subject: Re: [edk2] Query regarding hole in EFI Memory Map Of all the gin joints in all the towns in all the world, Prakhya, Sai Praneeth had to walk into mine at 16:30 on Monday 14 May 2018 and say: > Hi All, > > Recently, I have observed that there was a hole in EFI Memory Map > passed by firmware to Linux kernel. So, wanted to check with you if > this is expected or not. > > My Test setup: > I usually boot qemu with OVMF and Linux kernel. I use below command to > boot kernel. "qemu-system-x86_64 -cpu host -hda -serial > stdio -bios -m 2G -enable-kvm -smp 2" > > I have noticed that the EFI Memory Map (printed by kernel) is almost > contiguous but with only one hole ranging from 0xA0000 to 0x100000. As > far as I know, kernel hasn't modified this EFI Memory Map, so I am > assuming that firmware has passed memory map with a hole. I have > looked at UEFI spec "GetMemoryMap()" definition, and it says "The map > describes all of memory, no matter how it is being used". So, I am > thinking that EFI Memory Map shouldn't have any holes, am I correct? > If not, could someone please explain me the reason for this hole in EFI Memory Map. The map may describe all of physical RAM, however it is not necessarily the case that all available RAM be physically contiguous. With older IBM PCs based on the Intel 8088 processor, you could only have a 1MB address space. The first 640KB was available for RAM. The remaining space traditionally contained memory-mapped option ROMs, particularly for things like the video BIOS routines. The VGA text screen was also mapped to 0xB8000. Obviously, later processors made it possible to have additional memory above 1MB (sometimes called "high memory"), but for backward compatibility purposes, the gap from 0xA0000 to 0xFFFFF remained. So basically, on Intel machines you will always see this gap in RAM due to "hysterical raisins." It's just an artifact of the platform design. (And for that reason you'll see it both with the UEFI memory map facility and the legacy E820 BIOS facility). -Bill > > > Please let me know if you want me to post the EFI Memory Map or E820 > map that I am looking at. > > Note: I have also observed the same hole in E820 map. > > > > Regards, > > Sai > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel -- ============================================================================ = -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, wpaul@windriver.com | Master of Unix-Fu - Wind River Systems ============================================================================ = "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================ = _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel