GetMemoryMapSize wrong in pal_memory_create_info_table ?

[f4bjh]

Hi,

I'm facing issues with BSA TC #103 : "PE must access all NS addr space". I have then 2 questions :

From

sysarch-acs/pal/uefi_acpi/src/pal_peripherals.c

Line 288 in 44ddac5

Status = gBS->GetMemoryMap (&MemoryMapSize, MemoryMap, &MapKey, &DescriptorSize, &DescriptorVersion);

1/ Why did you prefer AllocatePages versus AllocatePool ?

2/In the Uefi Shell command library, MemoryMapSize is increased between 2 calls of GetMemoryMap : https://github.com/tianocore/edk2/blob/db38e5031a154897a0847c63072f657d00293820/ShellPkg/Library/UefiShellDebug1CommandsLib/MemMap.c#L385
Else MemoryMapSize is not set correctly in https://github.com/tianocore/edk2/blob/30b1cb6cabb95f1c385564957a7246882f828519/MdeModulePkg/Core/Dxe/Mem/Page.c#L2222

Would it be necessary to increase MemoryMapSize in pal_memory_create_info_table() as well ?
Else, second try of GetMemorySize still fails with returned status : EFI_BUFFER_TOO_SMALL, et TC #103 is failed.

Thanks in advance for your help.
Best regards,
Fabrice

[f4bjh]

Hello,

Did you have some time to look at this issue, please ?

Thanks in advance for your help.
Best regards,
Fabrice

[rajatgoyal47]

Hello Fabrice,

Please find my response.

AllocatePages() is not strictly required here; AllocatePool() would be sufficient since GetMemoryMap() operates on a byte-sized buffer and does not require page alignment. However, using AllocatePages() is still valid, provided the buffer size passed back to GetMemoryMap() correctly reflects the full allocated size.

As per UEFI behavior, GetMemoryMap() returns EFI_BUFFER_TOO_SMALL when the buffer is insufficient, and in that case updates MemoryMapSize with the required size at that point in time.

The expected flow is:

1. Call GetMemoryMap() → returns EFI_BUFFER_TOO_SMALL and sets MemoryMapSize
2. Allocate buffer using the returned MemoryMapSize
3. Update MemoryMapSize to reflect the actual allocated buffer size.
4. Call GetMemoryMap() again with the updated buffer and size

In the current implementation, although additional memory is allocated, the updated buffer size is not propagated back via MemoryMapSize before the second call. As a result, the second GetMemoryMap() may still return EFI_BUFFER_TOO_SMALL, leading to the observed failure in TC #103.

So yes, MemoryMapSize needs to be updated (or slightly increased) before retrying GetMemoryMap().

Have you had a chance to try this change locally and see if it resolves the issue on your side?