On Fri, 1 May 2026 at 17:38, Harsimran Singh Tungal <[email protected]> wrote: > > On 2026-04-27 19:04 +0200, Heinrich Schuchardt wrote: > > Am 27. April 2026 17:48:21 MESZ schrieb Ilias Apalodimas > > <[email protected]>: > > >Hi Harsiman, > > > > > >On Mon, 27 Apr 2026 at 18:05, Harsimran Singh Tungal > > ><[email protected]> wrote: > > >> > > >> Return EFI_NOT_FOUND for EFI_ALLOCATE_ADDRESS overlap > > >> > > >> When efi_allocate_pages() is called with EFI_ALLOCATE_ADDRESS, UEFI > > >> expects EFI_NOT_FOUND if the requested address range is already > > >> allocated or unavailable. > > >> U-Boot currently returns > > >> EFI_OUT_OF_RESOURCES when efi_update_memory_map() detects an overlap > > >> after a successful lmb_alloc_mem(), which does not match > > >> EFI_ALLOCATE_ADDRESS semantics. > > >> > > >> Return EFI_NOT_FOUND for EFI_ALLOCATE_ADDRESS requests that fail due > > >> to an overlapping EFI memory descriptor, while keeping > > >> EFI_OUT_OF_RESOURCES for other allocation types. > > >> > > >> The UEFI specification [1] specifies that > > >> EFI_BOOT_SERVICES.AllocatePages must return EFI_NOT_FOUND when the > > >> requested address range is unavailable or already allocated; > > >> EFI_OUT_OF_RESOURCES applies to non‑address‑specific allocation > > >> failures. > > > > > >Where does the EFI spec say that? EDKII indeed returns EFI_NOT_FOUND > > >for AllocateAddress but looking at the function description, I can't > > >find anything specific. > > > > > >Thanks > > >/Ilias > > > > Thank you Harsimran for investigating this difference to EDJ II. > > > > The spec has: > > > > EFI_NOT_FOUND > > The requested pages could not be found. > > > > and > > > > EFI_OUT_OF_RESOURCEST > > The pages could not be allocated. > > > > Looking at the text one could assume that EFI_NOT_FOUND should be returned > > if the pages requested with AllocateAddress don't exist in the memory map. > > > > If the pages exist and are already allocated EFI_NOT_FOUND does not look > > like the right return code according to the spec. > > > > It is unclear if for AllocateMaxAddress a comparison to the memory bottom > > is required. > > > > The specification should be clarified in the UEFI forum. > > > > Best regards > > > > Heinrich > > > > Hi Ilias, Hi Heinrich, > > Thanks for the clarification. > > You are right. > The AllocatePages() text only lists the generic status codes, and it > does not explicitly say that an AllocateAddress request on an already > allocated range must return EFI_NOT_FOUND. > > My motivation for this change was tlso he UEFI SCT expectation rather just a > direct statement in the UEFI base spec. The SCT AllocatePages tests expect > EFI_NOT_FOUND for AllocateAddress both with non-existent memory and with > allocated memory, and that is the behavior I was trying to align U-Boot > with, which matches with EDK II as well. > > Is this solution acceptable for now?
Yea, I am fine with that and the patch is fine, just tweak the commit message a bit and mention exactly that. That's it's unclear from reading the EFI spec, but we are better of doing what EDKII & SCT tests expect. Cheers /Ilias > > Thanks, > Harsimran Singh Tungal > > > > > > > > > >> > > >> [1] https://uefi.org/specs/UEFI/2.10_A/07_Services_Boot_Services.html > > >> > > >> Signed-off-by: Harsimran Singh Tungal <[email protected]> > > >> --- > > >> lib/efi_loader/efi_memory.c | 4 +++- > > >> 1 file changed, 3 insertions(+), 1 deletion(-) > > >> > > >> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c > > >> index b77c2f980cc..63cf1a7277f 100644 > > >> --- a/lib/efi_loader/efi_memory.c > > >> +++ b/lib/efi_loader/efi_memory.c > > >> @@ -510,7 +510,9 @@ efi_status_t efi_allocate_pages(enum > > >> efi_allocate_type type, > > >> /* Map would overlap, bail out */ > > >> lmb_free(addr, (u64)pages << EFI_PAGE_SHIFT, flags); > > >> unmap_sysmem((void *)(uintptr_t)efi_addr); > > >> - return EFI_OUT_OF_RESOURCES; > > >> + if (type == EFI_ALLOCATE_ADDRESS) > > >> + return EFI_NOT_FOUND; > > >> + return EFI_OUT_OF_RESOURCES; > > >> } > > >> > > >> *memory = efi_addr; > > >> -- > > >> 2.34.1 > > >> > > > > > >
