From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.31; helo=mga06.intel.com; envelope-from=sai.praneeth.prakhya@intel.com; receiver=edk2-devel@lists.01.org Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 B48C6207E4E09 for ; Mon, 14 May 2018 18:29:26 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2018 18:29:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,402,1520924400"; d="scan'208";a="58631781" Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by orsmga002.jf.intel.com with ESMTP; 14 May 2018 18:29:26 -0700 Received: from orsmsx157.amr.corp.intel.com (10.22.240.23) by ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 14 May 2018 18:29:25 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.24]) by ORSMSX157.amr.corp.intel.com ([169.254.9.36]) with mapi id 14.03.0319.002; Mon, 14 May 2018 18:29:25 -0700 From: "Prakhya, Sai Praneeth" To: Bill Paul , "edk2-devel@lists.01.org" CC: "Neri, Ricardo" Thread-Topic: [edk2] Query regarding hole in EFI Memory Map Thread-Index: AdPr2REpOMPrnedhTWCTzmfX7Cr+ZQAS2sCAAA40b9A= Date: Tue, 15 May 2018 01:29:25 +0000 Message-ID: References: <201805141812.37378.wpaul@windriver.com> In-Reply-To: <201805141812.37378.wpaul@windriver.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzgxZTdlMzEtODQ2ZC00N2Q3LTk0YjgtMDhmZDkwNmRkZmVhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiIzSXJ6WWk3bWdlZG5XYW1DXC83WmhxTmY3azJnRUZiT0pNejVcL29oY0p6ZVpPS1A3RFpSekZCa0l5Z2Zua25mT2IifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] MIME-Version: 1.0 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:29:26 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Of all the gin joints in all the towns in all the world, Prakhya, Sai Pra= neeth had to > walk into mine at 16:30 on Monday 14 May 2018 and say: >=20 > > 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. >=20 > The map may describe all of physical RAM, however it is not necessarily t= he case > that all available RAM be physically contiguous. >=20 > 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 s= pace > traditionally contained memory-mapped option ROMs, particularly for thing= s > like the video BIOS routines. The VGA text screen was also mapped to 0xB8= 000. >=20 > Obviously, later processors made it possible to have additional memory ab= ove > 1MB (sometimes called "high memory"), but for backward compatibility > purposes, the gap from 0xA0000 to 0xFFFFF remained. >=20 > So basically, on Intel machines you will always see this gap in RAM due t= o > "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 legac= y E820 > BIOS facility). Thanks a lot! for the explanation Bill. I really appreciate it :) Regards, Sai