I've been looking at this a bit. It appears that implementing PEI FreePool in this way would require:

* Adding a new HOB type EFI_HOB_TYPE_FREE_POOL to PiHob.h
* Adding a new FreePool PEI service to PiPeiCis.h
* Implementing the service in PeiMain.c and MemoryServices.c
* Adding PeiServicesFreePool() to PeiServicesLib
* Modifying PeiMemoryAllocationLib to call PeiServicesFreePool() when
  freeing EfiBootServicesData, while ignoring free requests for other
  memory types

The last step is a bit problematic, since PeiMemoryAllocationLib implements non-EfiBootServicesData pool allocations using AllocatePages(). FreePool() doesn't take a MemoryType parameter, so it just has to trust that it has been given a EfiBootServicesData buffer which was allocated from the HOB list. If a caller tries to free non-EfiBootServicesData memory, eg. memory allocated via AllocateRuntimePool(), the PEI service will return an error. PeiMemoryAllocationLib can ignore the error, since a failed free is essentially a no-op, which is the traditional implementation of FreePool() in PEI anyway.

Does that sound like an acceptable level of complexity and impact to the specifications? I'd rather not start the code first process if there's no chance it will go through.

An alternative would be to implement pool allocation and freeing entirely in PeiMemoryAllocationLib, instead of adding a new PEI service. If the code is too big, PeiMemoryAllocationLib could wrap a PPI. Then we could have different implementations, either backed by the HOB list like the current allocator, or backed by pages with a more sophisticated allocator.

Brian

-------- Original Message --------
From: Vincent Zimmer [mailto:vincent.zim...@gmail.com]
Sent: Wednesday, June 22, 2022, 4:59 PM
To: devel@edk2.groups.io, brian.john...@hpe.com
Subject: [edk2-devel] Clarification of Memory management in PEI phase

sounds like a good idea.  As a next step, perhaps a candidate activity
for https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Process
in anticipation of future inclusion in PI?
Vincent

On Wed, Jun 22, 2022 at 2:41 PM Brian J. Johnson <brian.john...@hpe.com> wrote:

Andrew,

Yes, adding a new HOB type to represent free pool would probably be the easiest.

Or we could write or borrow a traditional malloc() implementation, similar to 
DXE's pool allocator, and back it with memory from AllocatePages().  That would 
probably have better performance, and would avoid fragmenting the pool memory 
when non-pool HOBs are added.  It would probably be more code, though.

Brian J. Johnson
________________________________
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, June 22, 2022, 3:54 PM
To: Brian J. Johnson <brian.john...@hpe.com>
Cc: devel@edk2.groups.io, ayushdevel1...@gmail.com
Subject: [edk2-devel] Clarification of Memory management in PEI phase

Brian,

I think all the PEI Allocate Pool does is make a HOB [1]. I don’t think we can 
remove HOBs when memory is freed as that would change  pointers to pool. It may 
be possible to mark a region as free and allocate from that list batch 1st, and 
just over allocate space if needed. It could be as simple as just adding a new 
HOB type to represent free pool.


[1] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Memory/MemoryServices.c#L878

Thanks,

Andrew Fish

On Jun 22, 2022, at 12:39 PM, Brian J. Johnson <brian.johnson@hpe.comwrote:

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


--
Brian J. Johnson
Enterprise X86 Lab
Hewlett Packard Enterprise
brian.john...@hpe.com


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91002): https://edk2.groups.io/g/devel/message/91002
Mute This Topic: https://groups.io/mt/92114859/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to