On 06/23/2015 11:04 AM, Laszlo Ersek wrote:
> 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.
Whatever... I'm not going to dictate how you code it (not that my
opinion should have much weight for OVMF in the first place... I don't
regularly contribute to it.) As you said, it's a matter of duplicating
code one way or the other.
>
> 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.
Probably just Ia32X64. 32-bit DXE doesn't need page tables, and 64-bit
PEI already generates them somewhere else.
> 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.
>
--
Brian
--------------------------------------------------------------------
------------------------------------------------------------------------------
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
