From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=Z6dZW4BH; spf=pass (domain: apple.com, ip: 17.151.62.67, mailfrom: afish@apple.com) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) by groups.io with SMTP; Wed, 18 Sep 2019 10:10:42 -0700 Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x8IGvKHW027408; Wed, 18 Sep 2019 10:10:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=X+L03JjM5PqxPSPc2JMn4MfgTmulcUsaaUE3NDwxuss=; b=Z6dZW4BHFC/rgT252LjagIoeyqDxVFGtS7xiA/+3Vh+HgH/pcDkxYEYbYTJwBXyvenYt HRUqHBU53ZEKPANdqYP08TmzHC6vPzjztdMlf8cdTLNcNEEp1vGSYEOsKThwAiD/zKb2 nHiRvZwKP+pgGDpLBELb++oz6KrnBFqkPhnLkowspwDxAEUxTWoSh9TQgmx/BM4aUcED mUn0kldazOEGPdrFGSDuWJe0AUOgnlWzghSJtd4PohQxOzp8DNEexJ1VhwfYmGTMyZj9 JaKB7aYTMJeyDw1/BoD4yEh0yQiBG25ZQ/ydEz8Q8w4JNiUCA4MDFCMKfglKVKXjDLI7 yw== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2v37ujrd2j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Sep 2019 10:10:40 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PY100K10EDQFRK0@ma1-mtap-s02.corp.apple.com>; Wed, 18 Sep 2019 10:10:39 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PY100D00DNU1800@nwk-mmpp-sz09.apple.com>; Wed, 18 Sep 2019 10:10:38 -0700 (PDT) X-Va-A: X-Va-T-CD: ce96f226908f167d714f42ced545a0c1 X-Va-E-CD: 616ea11f349a1a914c63255b0bc479c3 X-Va-R-CD: 4943383b081b63e3a360ecb14fb24065 X-Va-CD: 0 X-Va-ID: f5b461dc-2096-41c3-919b-3fc8980a7f2a X-V-A: X-V-T-CD: ce96f226908f167d714f42ced545a0c1 X-V-E-CD: 616ea11f349a1a914c63255b0bc479c3 X-V-R-CD: 4943383b081b63e3a360ecb14fb24065 X-V-CD: 0 X-V-ID: 21c0dee0-75c1-487d-b3db-c31451a0ae16 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-18_09:,, signatures=0 Received: from [17.235.30.203] (unknown [17.235.30.203]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PY100J1JEDPJP20@nwk-mmpp-sz09.apple.com>; Wed, 18 Sep 2019 10:10:38 -0700 (PDT) Sender: afish@apple.com MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [edk2-devel] [edk2] DxeIpl : create page table, occupied too much memory range From: "Andrew Fish" In-reply-to: Date: Wed, 18 Sep 2019 10:10:36 -0700 Cc: Laszlo Ersek Message-id: <8424C048-188F-4D69-B94B-33A135381628@apple.com> References: <5eabf2c9104644ba955a4c3a4de983dc@zhaoxin.com> <2aca1445-6688-cb20-c0e3-938a4c4acd38@redhat.com> To: devel@edk2.groups.io, tigerliu@zhaoxin.com X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-18_09:,, signatures=0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Sep 18, 2019, at 3:50 AM, Tiger Liu(BJ-RD) wro= te: >=20 > Hi, Laszlo: > Thanks for your reply! >=20 > Is Using PcdUse5LevelPageTable also a method to reduce paging table's me= mory requirement? >=20 Tiger, No the 5-level page tables [1] are about increasing the size of the virtua= l addresses from 48 bits (256 terabytes) to 57 bits (128 petabytes). On x86= there are noncanonical addresses [2] in the middle of the virtual memory s= pace that will cause a GP fault if they are used since they can not be mapp= ed by page tables. The 5-level page table decreases the amount of noncanon= ical addressess in the virtual memory map, since the 5th level allows you t= o map more virtual addresses. I think from an EFI perspective you likely on= ly add a single page table entry unless your CPU supports more than 256 ter= abytes of physical address space.=20 > I find PcdUse1GPageTable's default value is false, why? The people who work for CPU companies will know more than me, but I seem t= o remember that 1GB page tables are common on modern server CPUs, but not o= n client CPUs. So I guess the PCD is just to remove a check that is likely = to fail [3]. If your system supports 1GB pages you can set PcdUse1GPageTabl= e to TRUE in your platforms DSC file.=20 Given EFI is identity mapped (Virtual address =3D=3D Physical address) and= Long Mode requires that paging is enabled you need page tables for any phy= sical address that is decoded by your chipset or memory controller (memory = or memory mapped IO).=20 If you look at this code [4] you will see you can configure how much of th= e address space requires page tables via the EFI_HOB_TYPE_CPU, if that HOB = is not present a CPU ID instruction is used to ask the processor how much p= hysical addressing it supports, and if that CPU ID feature is not present y= ou get the old answer of 36-bits.=20 So if you are trying to minimized page table generation you need to set EF= I_HOB_TYPE_CPU.SizeOfMemorySpace to a value that matches the highest memory= or memory mapped IO physical addresses you platform supports. Basically it= does not matter how much physical addressing your CPU supports if nothing = in your system is decoded by some of the upper address bits. PcdUse1GPageTa= ble is only going to help you if your CPU supports it.=20 >=20 > PcdUse5LevelPageTable's default value is true, and DxeIpl module will cr= eate 5-level paging for Dxe's long mode? >=20 As I mentioned you only need the 5 level page tables if your system has me= mory or memory mapped IO at an address greater than 256 terabytes (48-bits)= . [1] https://en.wikipedia.org/wiki/Intel_5-level_paging [2] https://en.wikipedia.org/wiki/X86-64 [3] https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/DxeIpl= Peim/X64/VirtualMemory.c#L667 [4] https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/DxeIpl= Peim/X64/VirtualMemory.c#L679 Thanks, Andrew Fish > Best wishes, >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Laszlo Ersek > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B49=E6=9C=8817=E6=97=A5= 20:07 > =E6=94=B6=E4=BB=B6=E4=BA=BA: devel@edk2.groups.io; Tiger Liu(BJ-RD) > =E4=B8=BB=E9=A2=98: Re: [edk2-devel] [edk2] DxeIpl : create page table, = occupied too much memory range >=20 > On 09/17/19 13:08, Tiger Liu(BJ-RD) wrote: >> Hi, Expert: >> I have a question about creating page table. >> If a CPU support 48bit physical address line, then creating page tables= (Page size=3D2MB) will occupy too much memory region. >>=20 >> Now, developer could only use PcdUse1GPageTable to avoid occupy too muc= h memory region? >=20 > Not only. See . >=20 > Thanks > Laszlo >=20 >=20 > =E4=BF=9D=E5=AF=86=E5=A3=B0=E6=98=8E=EF=BC=9A > =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=90=AB=E6=9C=89=E4=BF=9D=E5=AF=86=E6=88=96= = =E4=B8=93=E6=9C=89=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E4=BE=9B=E6=8C=87= =E5=AE=9A=E6=94=B6=E4=BB=B6=E4=BA=BA=E4=BD=BF=E7=94=A8=E3=80=82=E4=B8=A5= =E7=A6=81=E5=AF=B9=E6=9C=AC=E9=82=AE=E4=BB=B6=E6=88=96=E5=85=B6=E5=86=85= =E5=AE=B9=E5=81=9A=E4=BB=BB=E4=BD=95=E6=9C=AA=E7=BB=8F=E6=8E=88=E6=9D=83= =E7=9A=84=E6=9F=A5=E9=98=85=E3=80=81=E4=BD=BF=E7=94=A8=E3=80=81=E5=A4=8D= =E5=88=B6=E6=88=96=E8=BD=AC=E5=8F=91=E3=80=82 > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and i= s for the sole use of its intended recipient. Any unauthorized review, use,= copying or forwarding of this email or the content of this email is strict= ly prohibited. >=20 >=20 >=20