On 06/23/15 16:51, Brian J. Johnson wrote: > On 06/23/2015 02:26 AM, Laszlo Ersek wrote: >> On 06/22/15 21:53, Jordan Justen wrote: >>> On 2015-06-22 12:22:54, Brian J. Johnson wrote: >>>> I stuck those calculations in gnumeric (assuming Page1GSupport==FALSE) >>>> and got this: >>>> >>>> PABits Pml4 Pdp TotPgs MB >>>> ------ ---- --- ------ -- >>>> 36 1 64 66 0.258 >>>> 37 1 128 130 0.508 >>>> 38 1 256 258 1.008 >>>> 39 1 512 514 2.008 >>>> 40 2 512 1027 4.012 >>>> 41 4 512 2053 8.020 >>>> 42 8 512 4105 16.035 >>>> 43 16 512 8209 32.066 >>>> 44 32 512 16417 64.129 >>>> 45 64 512 32833 128.254 >>>> 46 128 512 65665 256.504 >>>> 47 256 512 131329 513.004 >>>> 48 512 512 262657 1026.004 >>>> >>>> So 48 bits of PA should take just over a GB of page tables. >> >> Thank you Brian for this! >> >>>> Can you set PcdUse1GPageTable=TRUE? That vastly reduces the number of >>>> page table pages needed, and vastly reduces the time needed to >>>> initialize them. Just wondering. (I've found that some older >>>> Microsoft >>>> boot loaders don't like this setting, but I haven't tried the newer >>>> ones. Linux is fine with it.) >>> >>> Sound kind of complicated to tell if it is okay to use. Although, >>> maybe if we just use it dynamically when memory space is larger than >>> say 36 bits, then perhaps the risk of people running an unsupported >>> configuration is also low. >> >> How about I simply add a switch statement and hardcode the values from >> Brian's table, and after the switch I add 64MB for "misc"? > > Personally I can't stand hardcoded constants. I'd much rather see the > "real" calculation, based on the code from > CreateIdentityMappingPageTables().
Unless the real calculation is extracted from CreateIdentityMappingPageTables() into a library, and reused by both the original function and the new OVMF call site (via function calls), we're just talking different degrees of open coding. In one case the results of the calculation would be hard-coded, in the other case the calculation itself would be hard-coded (but still not shared with the code that actually allocates the memory). If the algorithm is architecturally dictated, and uniquely defined, then so are its results. > It's pretty straightforward, really: > calculate the number of PML4 and PDP entries needed based on the PA > size, via a couple of shifts. Then convert that to pages: one page for > the PML4s, one page per PML4 for the PDPs, and one page per PDP for the > PDEs: > > Pages = 1 + Pml4 + (Pml4 * Pdp) = (Pdp + 1) * Pml4 + 1 > > If you're using 1GB pages, then there are no PDEs, so: > > Pages = 1 + Pml4 > > That matches the code in CreateIdentityMappingPageTables(). And it's > all architectural for x86, so it's not likely to change. Thanks for summarizing it. Although I still disagree with replicating the calculation in OvmfPkg, I can try implementing it. But then, please don't point out that this code is specific to X64 (and Ia32X64), and a 32-bit DXE works differently, and that *too* should be replicated in the OVMF code. That's just hugely overkill. The patch I submitted is agnostic to the word size of DXE. Actually: does anyone feel inclined to take on this patch? (Feel free to grab this patch as basis.) Thanks Laszlo > > If you want to simplify the calculations a bit, you could assume at > least 39 PA bits. Then the only variable is the number of PML4 entries > needed, which is just 1 << (PASize - 39). > > But that's my opinion. There's always some estimating involved in code > like this, since you don't know exactly how much memory will be > allocated dynamically. ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
