Sorry for the late response to this thread...
PEI has grown greatly in complexity, as Andrew pointed out. Do we
(TianoCore community) think it's time to add a real pool manager to
PEI? There's getting to be quite a bit of post-DRAM-initialization PEI
code on some platforms. And really, having a limited amount of pre-DRAM
memory available is an even better reason for having an effective pool
allocator, so the memory can be freed and reused.
FWIW we (HPE) needed to add a private pool allocator to manage memory
for a proprietary h/w initialization module which needs to run in
post-DRAM PEI, and depends on allocating and freeing memory in different
phases of its operation.
Brian J. Johnson
------------------------------------------------------------------------
*From:* Ayush Singh [mailto:ayushdevel1...@gmail.com]
*Sent:* Friday, June 10, 2022, 12:22 AM
*To:* Andrew Fish <af...@apple.com>
*Cc:* devel@edk2.groups.io
*Subject:* [edk2-devel] Clarification of Memory management in PEI phase
Thanks for the wonderful answer.
Ayush Singh
On Thu, Jun 9 2022 at 01:26:58 PM -0700, Andrew Fish <af...@apple.com>
wrote:
On Jun 9, 2022, at 10:28 AM, Ayush Singh
<ayushdevel1325@gmail.comwrote: Hello everyone, Can anyone help
me with understanding dynamic memory management in PEI phase? In
the UEFI Platform Integration Specification, version 1.7 Errata
A, Section 4.6, PEI Memory services are given which include: 1.
InstallPeiMemory()
This is basically: (*PeiServices)->InstallPeiMemory (PeiServices,
MemoryBegin, MemoryLength); This is how you tell the PEI Core the
location of the memory that will can be used in PEI.
2. AllocatePages() 3. AllocatePool() 4. CopyMem() 5. SetMem() 6.
FreePages() However, no `FreePool()` service seems to be present.
So how is the memory allocated using `AllocatePool()` freed?
It basically gets Freed when you transition to the DXE phase. To step
back for a minute I think it is important to remember that the main
job of PEI is to initialize DRAM, and deal with S3 (resuming from
suspend to RAM). So as soon as you have DRAM you are kind done and
ready for the DXE IPL so you can load the DXE Phase and start up EFI.
Remember PEI is Pre EFI. The reality is programming DRAM is complex
and lots of code got written, then lots more code got written and PEI
has become large for some ports. That was never the intent. PEI is
designed as a way to run C code when you code is running from ROM and
you donā��t have any DRAM. For x86 not having DRAM means you are
using the cache as RAM. For some SoCs there is actually an SRAM you
can use. Thus the PEI memory allocation scheme is designed to deal
with this very constrained environment. You start PEI with a heap and
stack. You can also allocate HOBs (Hand Off Blocks). A pool
allocation in PEI is just a HOB. See [1]. There is no way to free a
HOB. So the AllocatePool() kind of leaks into DXE too as an entry in
the HOB list. But when the OS called gBS->ExitBootServices() that
frees all non runtime memory back to the OS. If you look a
AllocatePages/FreePages you will see AllocatePages creates a HOB that
points to the memory region, and FreePages just marks that HOB as not
used. That code is also in this file [1]. TL;DR there is no pool
manager in PEI. [1]
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Memory/MemoryServices.c#L878
Thanks, Andrew Fish
Ayush Singh
Brian
------------------------------------------------------------------------------------------------------------------------------
"It's OK to be stuck. 99% of the time in your own [research] work,
you're stuck."
-- Mark Lawrence
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90695): https://edk2.groups.io/g/devel/message/90695
Mute This Topic: https://groups.io/mt/91651322/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
