[QUESTION] reservation of pool allocations performed during PEI

[QUESTION] reservation of pool allocations performed during PEI

[Ard Biesheuvel]

After a recent change to the AArch64 page table code, the root table
of the page tables is allocated using AllocatePool() rather than
AllocatePages() if its size is much smaller than a page. E.g., when
using 40 bits of translation, the root table only takes up 16 bytes

However, what I have noticed is that pool allocations made during PEI
are listed as available memory in the EFI memory map (using memmap in
the UEFI Shell). Is this expected? Is it part of the contract that
AllocatePool() allocations are lost when entering DXE?

Thanks,
Ard.

Re: [QUESTION] reservation of pool allocations performed during PEI

[Laszlo Ersek]

On 01/20/17 17:05, Ard Biesheuvel wrote:
> After a recent change to the AArch64 page table code, the root table
> of the page tables is allocated using AllocatePool() rather than
> AllocatePages() if its size is much smaller than a page. E.g., when
> using 40 bits of translation, the root table only takes up 16 bytes
> 
> However, what I have noticed is that pool allocations made during PEI
> are listed as available memory in the EFI memory map (using memmap in
> the UEFI Shell). Is this expected? Is it part of the contract that
> AllocatePool() allocations are lost when entering DXE?

Pool allocations in PEI are satisfied with HOBs (and therefore the pool
allocation sizes are limited to ~64KB).

In addition, soon after permanent PEI RAM is installed, objects from the
temporary SEC/PEI heap are moved there (this is called "temporary RAM
migration"). This includes the migration of the full HOB list, including
those that were used to satisfy pool allocations prior to RAM migration.

If you want to allocate memory in PEI that is to survive in-place into
DXE and later, I can think of two ways:

- Call AllocatePages. This will only work after permanent PEI RAM has
been installed (so you might want to make the PEIM performing the call
dependent on gEfiPeiMemoryDiscoveredPpiGuid, with a DEPEX). The
allocation will be carved out of the permanent PEI RAM.

- Allocate a region (a whole multiple of pages) outside of the permanent
PEI RAM, but in a spot that will later on be backed by system memory
(due to a system memory resource descriptor HOB produced in PEI, or due
to a GCD memory space addition during DXE). The way to perform this kind
of allocation is simply to produce a memory allocation HOB, covering the
range in question. This works even before the installation of permanent
PEI RAM.

... I hope I remembered most of this stuff right.

Thanks
Laszlo

Re: [QUESTION] reservation of pool allocations performed during PEI

[Ard Biesheuvel]

On 20 January 2017 at 16:38, Laszlo Ersek <lersek@redhat.com> wrote:
> On 01/20/17 17:05, Ard Biesheuvel wrote:
>> After a recent change to the AArch64 page table code, the root table
>> of the page tables is allocated using AllocatePool() rather than
>> AllocatePages() if its size is much smaller than a page. E.g., when
>> using 40 bits of translation, the root table only takes up 16 bytes
>>
>> However, what I have noticed is that pool allocations made during PEI
>> are listed as available memory in the EFI memory map (using memmap in
>> the UEFI Shell). Is this expected? Is it part of the contract that
>> AllocatePool() allocations are lost when entering DXE?
>
> Pool allocations in PEI are satisfied with HOBs (and therefore the pool
> allocation sizes are limited to ~64KB).
>
> In addition, soon after permanent PEI RAM is installed, objects from the
> temporary SEC/PEI heap are moved there (this is called "temporary RAM
> migration"). This includes the migration of the full HOB list, including
> those that were used to satisfy pool allocations prior to RAM migration.
>

So how is this supposed to work for code that holds a pointer to such
a pool allocation?

> If you want to allocate memory in PEI that is to survive in-place into
> DXE and later, I can think of two ways:
>
> - Call AllocatePages. This will only work after permanent PEI RAM has
> been installed (so you might want to make the PEIM performing the call
> dependent on gEfiPeiMemoryDiscoveredPpiGuid, with a DEPEX). The
> allocation will be carved out of the permanent PEI RAM.
>

The same code calls AllocatePages for the subsequent translation
levels, i.e., when using 40 bits of translation, there are 4 levels,
where all but the top level are full pages. So I could simply replace
AllocatePool with AllocaPages in this case, which would effectively
revert my 'improvement' to this code to use a pool allocation for the
root level.

> - Allocate a region (a whole multiple of pages) outside of the permanent
> PEI RAM, but in a spot that will later on be backed by system memory
> (due to a system memory resource descriptor HOB produced in PEI, or due
> to a GCD memory space addition during DXE). The way to perform this kind
> of allocation is simply to produce a memory allocation HOB, covering the
> range in question. This works even before the installation of permanent
> PEI RAM.
>
> ... I hope I remembered most of this stuff right.
>

Thanks for the lesson :-)

Re: [QUESTION] reservation of pool allocations performed during PEI

[Laszlo Ersek]

On 01/20/17 17:38, Laszlo Ersek wrote:
> On 01/20/17 17:05, Ard Biesheuvel wrote:
>> After a recent change to the AArch64 page table code, the root table
>> of the page tables is allocated using AllocatePool() rather than
>> AllocatePages() if its size is much smaller than a page. E.g., when
>> using 40 bits of translation, the root table only takes up 16 bytes
>>
>> However, what I have noticed is that pool allocations made during PEI
>> are listed as available memory in the EFI memory map (using memmap in
>> the UEFI Shell). Is this expected? Is it part of the contract that
>> AllocatePool() allocations are lost when entering DXE?
> 
> Pool allocations in PEI are satisfied with HOBs (and therefore the pool
> allocation sizes are limited to ~64KB).
> 
> In addition, soon after permanent PEI RAM is installed, objects from the
> temporary SEC/PEI heap are moved there (this is called "temporary RAM
> migration"). This includes the migration of the full HOB list, including
> those that were used to satisfy pool allocations prior to RAM migration.
> 
> If you want to allocate memory in PEI that is to survive in-place into
> DXE and later, I can think of two ways:
> 
> - Call AllocatePages. This will only work after permanent PEI RAM has
> been installed (so you might want to make the PEIM performing the call
> dependent on gEfiPeiMemoryDiscoveredPpiGuid, with a DEPEX). The
> allocation will be carved out of the permanent PEI RAM.
> 
> - Allocate a region (a whole multiple of pages) outside of the permanent
> PEI RAM, but in a spot that will later on be backed by system memory
> (due to a system memory resource descriptor HOB produced in PEI, or due
> to a GCD memory space addition during DXE). The way to perform this kind
> of allocation is simply to produce a memory allocation HOB, covering the
> range in question. This works even before the installation of permanent
> PEI RAM.
> 
> ... I hope I remembered most of this stuff right.

You mention that AllocatePages() used to work in the same spot; that
means that it occurs after permanent PEI RAM installation, hence (likely
-- there's a very small gap) after temoprary RAM migration too. Hence,
the HOBs should have been migrated to permanent PEI RAM already.

I very vaguely recall / suspect that HOBs are again moved when DXE
starts up?... Should check in the PI spec, but it's Friday...

I recommend sticking with AllocatePages(), if it can work in the spot in
question; otherwise a memalloc HOB.

Laszlo

Re: [QUESTION] reservation of pool allocations performed during PEI

[Laszlo Ersek]

On 01/20/17 17:42, Ard Biesheuvel wrote:
> On 20 January 2017 at 16:38, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 01/20/17 17:05, Ard Biesheuvel wrote:
>>> After a recent change to the AArch64 page table code, the root table
>>> of the page tables is allocated using AllocatePool() rather than
>>> AllocatePages() if its size is much smaller than a page. E.g., when
>>> using 40 bits of translation, the root table only takes up 16 bytes
>>>
>>> However, what I have noticed is that pool allocations made during PEI
>>> are listed as available memory in the EFI memory map (using memmap in
>>> the UEFI Shell). Is this expected? Is it part of the contract that
>>> AllocatePool() allocations are lost when entering DXE?
>>
>> Pool allocations in PEI are satisfied with HOBs (and therefore the pool
>> allocation sizes are limited to ~64KB).
>>
>> In addition, soon after permanent PEI RAM is installed, objects from the
>> temporary SEC/PEI heap are moved there (this is called "temporary RAM
>> migration"). This includes the migration of the full HOB list, including
>> those that were used to satisfy pool allocations prior to RAM migration.
>>
> 
> So how is this supposed to work for code that holds a pointer to such
> a pool allocation?

It's not.

Against such HOBs, don't hold a pointer, hold a grudge. :)

> 
>> If you want to allocate memory in PEI that is to survive in-place into
>> DXE and later, I can think of two ways:
>>
>> - Call AllocatePages. This will only work after permanent PEI RAM has
>> been installed (so you might want to make the PEIM performing the call
>> dependent on gEfiPeiMemoryDiscoveredPpiGuid, with a DEPEX). The
>> allocation will be carved out of the permanent PEI RAM.
>>
> 
> The same code calls AllocatePages for the subsequent translation
> levels, i.e., when using 40 bits of translation, there are 4 levels,
> where all but the top level are full pages. So I could simply replace
> AllocatePool with AllocaPages in this case,

Yes, I think so.

> which would effectively
> revert my 'improvement' to this code to use a pool allocation for the
> root level.
> 
>> - Allocate a region (a whole multiple of pages) outside of the permanent
>> PEI RAM, but in a spot that will later on be backed by system memory
>> (due to a system memory resource descriptor HOB produced in PEI, or due
>> to a GCD memory space addition during DXE). The way to perform this kind
>> of allocation is simply to produce a memory allocation HOB, covering the
>> range in question. This works even before the installation of permanent
>> PEI RAM.
>>
>> ... I hope I remembered most of this stuff right.
>>
> 
> Thanks for the lesson :-)
> 

You certainly got what you paid for! ;)