Re: "practical" memory allocation limit?

[Laszlo Ersek <lersek@redhat.com>]

On 08/28/17 18:23, Andrew Fish wrote:
> For X64 (x86-64) systems it is common for PEI to run in 32-bit mode
> with paging disabled. This means the DXE Core gets loaded under 4GB
> and and the HOBs and such are < 4GB. So having the initial memory map
> < 4GB helps with preventing fragmentation.

Hmm OK. That makes sense, thanks.

>
> There is also architectural cruft on x86. Historically some of the PCI
> devices did not support DMA > 4GB and the system needed memory under
> for DMA buffers. The other problem is processor mode transitions as
> real mode code needs to be < 1MB and 32-bit protected mode needs to be
> under 4GB. To get into the 64-bit long mode you start in real mode,
> transition to protected mode, and then enter long mode. Even in 2017
> there are still real mode entry points required for x86, mainly the
> reset vector, and IPI for the AP (how you wake up the other CPUs even
> in the OS). If you are using a CSM and need to get into real mode I
> think the thunk code assumes it runs < 4G (at least it did a long time
> ago).
>
> Not to mention just general cruft in the code that has assumptions
> about running < 4G (things like AsmThunk16(), CPU drivers etc.).

Right, I've seen several examples for this in edk2; I just didn't
understand why the "normal" stuff would get allocated by default under
4G. Mitigating fragmentation explains it though, thanks!

>> On Aug 28, 2017, at 8:31 AM, Shi, Steven <steven.shi@intel.com>
>> wrote:
>>
>> OK, got it. Thanks.

(Um... looks like your email was technically in response to Steven's...
but I got only yours (thus far), not Steven's.)

>> For the why the 64bits DXE usually prefer allocations below 4GB,
>> there is a good white paper elaborate the memory service
>> initialization flows and can explain the reason. Please see the page
>> 23 in below white paper (I have mark the answer in red).
>>
>> https://github.com/tianocore-docs/Docs/blob/master/White_Papers/A_Tour_Beyond_BIOS_Securiy_Enhancement_to_Mitigate_Buffer_Overflow_in_UEFI.pdf
>>
>> Heap Management in EDK II
>> In UEFI, the DxeCore maintains the heap usage. The UEFI driver or
>> application may call AllocatePages/FreePages/AllocatePool/FreePool to
>> allocate or free the resource, or call GetMemoryMap() to review all
>> of the memory usage.
>> [Heap Initialization]
>> When DxeIpl transfers control to the DxeCore, all of the resource
>> information is reported in a Hand-off-Block (HOB) [PI] list. The
>> DxeCore constructs the heap based upon the HOB information. See
>> figure 4-2 Heap Initialization.
>> 1) The DxeCore needs to find one region to serve as the initial
>> memory in CoreInitializeMemoryServices()
>> (https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Gcd/Gcd.c).
>> The function is responsible for priming the memory map so that memory
>> allocations and resource allocations can be made. If the memory
>> region described by the PHIT HOB is big enough to hold BIN and
>> minimum initial memory, this memory region is used as highest
>> priority. It can make the memory BIN allocation to be at the same
>> memory region with PHIT that has better compatibility to avoid memory
>> fragmentation. Usually the BIN size is already considered by platform
>> PEIM when the platform PEIM calls InstallPeiMemory() to PEI core.

The top-posting got even more confusing here (I honestly can't tell who
quoted this from the whitepaper), but it answers my question. To
whomever I have to thank for it: thank you. :)

Laszlo