From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 23 Jul 2019 12:20:07 -0700 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4D24881F1B; Tue, 23 Jul 2019 19:20:07 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-52.ams2.redhat.com [10.36.117.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id 10CE260603; Tue, 23 Jul 2019 19:20:05 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 4/4] MdeModulePkg/DxeIpl: Create 5-level page table for long mode To: "Ni, Ray" , "devel@edk2.groups.io" Cc: "Dong, Eric" References: <20190722081547.56100-1-ray.ni@intel.com> <20190722081547.56100-5-ray.ni@intel.com> <734D49CCEBEEF84792F5B80ED585239D5C2417DB@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <6cc63718-a546-8b80-022d-d1a76cff081d@redhat.com> Date: Tue, 23 Jul 2019 21:20:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C2417DB@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 23 Jul 2019 19:20:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/23/19 17:29, Ni, Ray wrote: > > >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Laszlo Ersek >> Sent: Tuesday, July 23, 2019 5:46 PM >> To: devel@edk2.groups.io; Ni, Ray >> Cc: Dong, Eric >> Subject: Re: [edk2-devel] [PATCH 4/4] MdeModulePkg/DxeIpl: Create 5-level page table for long mode >> >> On 07/22/19 10:15, Ni, Ray wrote: >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008 >>> >>> DxeIpl is responsible to create page table for DXE phase running >>> either in long mode or in 32bit mode with certain protection >>> mechanism enabled (refer to ToBuildPageTable()). >>> >>> The patch updates DxeIpl to create 5-level page table for DXE phase >>> running in long mode when PcdUse5LevelPageTable is TRUE and CPU >>> supports 5-level page table. >>> >>> Signed-off-by: Ray Ni >>> Cc: Eric Dong >>> Cc: Laszlo Ersek >>> --- >>> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 1 + >>> .../Core/DxeIplPeim/X64/VirtualMemory.c | 227 ++++++++++++------ >>> 2 files changed, 151 insertions(+), 77 deletions(-) >>> >>> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>> index abc3217b01..98bc17fc9d 100644 >>> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>> @@ -110,6 +110,7 @@ [Pcd.IA32,Pcd.X64] >>> gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask ## CONSUMES >>> gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask ## CONSUMES >>> gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard ## CONSUMES >>> + gEfiMdeModulePkgTokenSpaceGuid.PcdUse5LevelPageTable ## SOMETIMES_CONSUMES >>> >>> [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64] >>> gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack ## SOMETIMES_CONSUMES >>> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c >>> index edc38e4525..a5bcdcc734 100644 >>> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c >>> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c >>> @@ -15,7 +15,7 @@ >>> 2) IA-32 Intel(R) Architecture Software Developer's Manual Volume 2:Instruction Set Reference, Intel >>> 3) IA-32 Intel(R) Architecture Software Developer's Manual Volume 3:System Programmer's Guide, Intel >>> >>> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>>> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>>> Copyright (c) 2017, AMD Incorporated. All rights reserved.
>>> >>> SPDX-License-Identifier: BSD-2-Clause-Patent >>> @@ -626,14 +626,19 @@ CreateIdentityMappingPageTables ( >>> ) >>> { >>> UINT32 RegEax; >>> + UINT32 RegEbx; >>> + UINT32 RegEcx; >>> UINT32 RegEdx; >>> UINT8 PhysicalAddressBits; >>> EFI_PHYSICAL_ADDRESS PageAddress; >>> + UINTN IndexOfPml5Entries; >>> UINTN IndexOfPml4Entries; >>> UINTN IndexOfPdpEntries; >>> UINTN IndexOfPageDirectoryEntries; >>> + UINT32 NumberOfPml5EntriesNeeded; >>> UINT32 NumberOfPml4EntriesNeeded; >>> UINT32 NumberOfPdpEntriesNeeded; >>> + PAGE_MAP_AND_DIRECTORY_POINTER *PageMapLevel5Entry; >>> PAGE_MAP_AND_DIRECTORY_POINTER *PageMapLevel4Entry; >>> PAGE_MAP_AND_DIRECTORY_POINTER *PageMap; >>> PAGE_MAP_AND_DIRECTORY_POINTER *PageDirectoryPointerEntry; >>> @@ -641,9 +646,11 @@ CreateIdentityMappingPageTables ( >>> UINTN TotalPagesNum; >>> UINTN BigPageAddress; >>> VOID *Hob; >>> + BOOLEAN Page5LevelSupport; >>> BOOLEAN Page1GSupport; >>> PAGE_TABLE_1G_ENTRY *PageDirectory1GEntry; >>> UINT64 AddressEncMask; >>> + IA32_CR4 Cr4; >>> >>> // >>> // Make sure AddressEncMask is contained to smallest supported address field >>> @@ -677,33 +684,66 @@ CreateIdentityMappingPageTables ( >>> } >>> } >>> >>> + Page5LevelSupport = FALSE; >>> + if (PcdGetBool (PcdUse5LevelPageTable)) { >>> + AsmCpuidEx (0x7, 0, &RegEax, &RegEbx, &RegEcx, &RegEdx); >>> + DEBUG ((DEBUG_INFO, "Cpuid(7/0): %08x/%08x/%08x/%08x\n", RegEax, RegEbx, RegEcx, RegEdx)); >>> + if ((RegEcx & BIT16) != 0) { >> >> (1) Would it be possible to use macro names here, for Index and SubIndex >> in AsmCpuidEx(), and a "better" macro name than BIT16, in the RegEcx check? > > There are macros which are defined in UefiCpuPkg for the CPUID leaf functions > and structures for the CPUID output data. > But since there is rule that MdeModulePkg cannot depend on UefiCpuPkg so > the code cannot use those macros/structures. > > I am thinking of a new rule that UefiCpuPkg and MdeModulePkg can depend on each other. > I haven't talked with Mike on this. Not sure if he is ok on this. > For this case, yes I can temporary define 2 macros: one for 0x7, the other for BIT16. I'm aware of this restriction. I think it's a good one; personally I wouldn't like MdeModulePkg to depend on UefiCpuPkg. For example, while MdeModulePkg is very necessary for AARCH64 platforms, UefiCpuPkg doesn't appear necessary for AARCH64 platforms. If both MdeModulePkg and UefiCpuPkg depend on such macros, then the macros should arguably be defined in "MdeModulePkg/Include/IndustryStandard", or even "MdePkg/Include/IndustryStandard". The registers and bit-fields come from published industry specifications. (Published by Intel :) ) >>> + Page5LevelSupport = TRUE; >>> + } >>> + } >>> + >>> + DEBUG ((DEBUG_INFO, "AddressBits/5LevelPaging/1GPage = %d/%d/%d\n", PhysicalAddressBits, Page5LevelSupport, >> Page1GSupport)); >>> + >> >> (2) Can we format this log message as: >> >> AddressBits=%d 5LevelPaging=%d 1GPage=%d > > ok. > >> >> ? >> >>> // >>> - // IA-32e paging translates 48-bit linear addresses to 52-bit physical addresses. >>> + // IA-32e paging translates 48-bit linear addresses to 52-bit physical addresses >>> + // when 5-Level Paging is disabled, >>> + // due to either unsupported by HW, or disabled by PCD. >>> // >>> ASSERT (PhysicalAddressBits <= 52); >>> - if (PhysicalAddressBits > 48) { >>> + if (!Page5LevelSupport && PhysicalAddressBits > 48) { >>> PhysicalAddressBits = 48; >>> } >>> >>> // >>> // Calculate the table entries needed. >>> // >>> - if (PhysicalAddressBits <= 39 ) { >>> - NumberOfPml4EntriesNeeded = 1; >>> - NumberOfPdpEntriesNeeded = (UINT32)LShiftU64 (1, (PhysicalAddressBits - 30)); >>> - } else { >>> - NumberOfPml4EntriesNeeded = (UINT32)LShiftU64 (1, (PhysicalAddressBits - 39)); >>> - NumberOfPdpEntriesNeeded = 512; >>> + NumberOfPml5EntriesNeeded = 1; >>> + if (PhysicalAddressBits > 48) { >>> + NumberOfPml5EntriesNeeded = (UINT32) LShiftU64 (1, PhysicalAddressBits - 48); >>> + PhysicalAddressBits = 48; >>> } >>> >>> + NumberOfPml4EntriesNeeded = 1; >>> + if (PhysicalAddressBits > 39) { >>> + NumberOfPml4EntriesNeeded = (UINT32) LShiftU64 (1, PhysicalAddressBits - 39); >>> + PhysicalAddressBits = 39; >>> + } >>> + >>> + NumberOfPdpEntriesNeeded = 1; >>> + ASSERT (PhysicalAddressBits > 30); >>> + NumberOfPdpEntriesNeeded = (UINT32) LShiftU64 (1, PhysicalAddressBits - 30); >>> + >>> // >>> // Pre-allocate big pages to avoid later allocations. >>> // >>> if (!Page1GSupport) { >>> - TotalPagesNum = (NumberOfPdpEntriesNeeded + 1) * NumberOfPml4EntriesNeeded + 1; >>> + TotalPagesNum = ((NumberOfPdpEntriesNeeded + 1) * NumberOfPml4EntriesNeeded + 1) * NumberOfPml5EntriesNeeded >> + 1; >>> } else { >>> - TotalPagesNum = NumberOfPml4EntriesNeeded + 1; >>> + TotalPagesNum = (NumberOfPml4EntriesNeeded + 1) * NumberOfPml5EntriesNeeded + 1; >>> + } >>> + >>> + // >>> + // Substract the one page occupied by PML5 entries if 5-Level Paging is disabled. >>> + // >>> + if (!Page5LevelSupport) { >>> + TotalPagesNum--; >>> } >>> + >>> + DEBUG ((DEBUG_INFO, "Pml5/Pml4/Pdp/TotalPage = %d/%d/%d/%d\n", >>> + NumberOfPml5EntriesNeeded, NumberOfPml4EntriesNeeded, >>> + NumberOfPdpEntriesNeeded, TotalPagesNum)); >>> + >> >> (3) Same comment about log message formatting as in (2). >> >> (4) Please log UINT32 values with %u, not %d. >> >> (5) Please log UINTN values with %Lu (and cast them to UINT64 first). > > > ok to above 3, 4, 5. > >> >> (6) More generally, can we please replace this patch with three patches, >> in the series? >> >> - the first patch should extract the TotalPagesNum calculation to a >> separate *library* function (it should be a public function in a BASE or >> PEIM library) >> >> - the second patch should extend the TotalPagesNum calculation in the >> library function to 5-level paging >> >> - the third patch should be the remaining code from the present patch. >> >> Here's why: in OvmfPkg/PlatformPei, the GetPeiMemoryCap() function >> duplicates this calculation. In OVMF, PEI-phase memory allocations can >> be dominated by the page tables built for 64-bit DXE, and so >> OvmfPkg/PlatformPei must know, for sizing the permanent PEI RAM, how >> much RAM the DXE IPL PEIM will need for those page tables. >> >> I would *really* dislike copying this update (for 5-level paging) from >> CreateIdentityMappingPageTables() to GetPeiMemoryCap(). Instead, the >> calculation should be extracted to a library function, and then OVMF >> (and all other platforms affected similarly) could call the new function. >> >> If this is not feasible or very much out of scope, then I guess we'll >> just keep the PCD as FALSE in OVMF, for the time being. >> > > BZ https://bugzilla.tianocore.org/show_bug.cgi?id=847 may be what > you need. Oh, indeed. I'm subscribed to this BZ, but the last update was in Jan 2018 :) > Extracting a library API to return how many pages are needed for page tables > needs to consider several cases: > 1. 4K or 2M or 1G page size is used. > 2. range of physical memory > 3. page table level > > But right now, this is not in the high priority in my to-do list. > I can help to change GetPeiMemoryCap() for short-term needs. > Are you ok with this? No, I'm not. Obviously, I'm not trying to force you to abstract out the library in question, just for OVMF's sake. What I'm saying is that I strongly prefer delaying 5-level paging support in OVMF until this library becomes available, over duplicating yet more code (and complex code, at that) from other Packages to OvmfPkg. From that perspective, I appreciate the new PCD very much, because it should make this postponing easy. In other words, there is no short-term need. Thank you! Laszlo