efi_memmap_init_late(9)

📦 version 7.3.1, in nixpkgs unstable

💅 efi_memmap_init_late(9) — a kernel API manual, bestie edition

okay so this is a page from the Kernel API Manual, and today's main character is efi_memmap_init_late 🎀

✨ NAME ✨

efi_memmap_init_late — literally just maps efi.memmap with memremap() 🗺️✨

🌸 SYNOPSIS 🌸

int efi_memmap_init_late (phys_addr_t addr , unsigned long size );

🦋 ARGUMENTS 🦋

  • addr — the physical address of the new EFI memory map. yes bestie, physical, keep up 💖
  • size — how big the new EFI memory map is, in bytes 📏

💜 DESCRIPTION 💜

So what this does is set up a mapping of the EFI memory map using ioremap_cache ✨.

⚠️ But listen — this function should only be called once the vmalloc space has been set up. Which means it is not suitable for calling during early EFI initialise, like, for example in efi_init. Not the vibe. 🙅‍♀️

Also it expects efi_memmap_init_early to have already been called. Prerequisite behavior, iykyk 🫶

Now, why are there two EFI memmap initialisation functions (efi_memmap_init_early and this late one, hi bestie)? 👀 Because the early EFI memmap should be explicitly unmapped once EFI initialisation is complete — the fixmap space used to map the EFI memmap (via early_memremap) is a scarce resource, and we are not wasting it 💀

The late mapping (that's this one, the one we're talking about 💅) is intended to persist for the duration of runtime, so that things like efi_mem_desc_lookup and efi_mem_attributes always work. iconic of it honestly 👑

⭐ RETURN ⭐

  • zero on success 🎉
  • a negative error code on failure 😭

🔥 SEE ALSO 🔥

okay that's the whole page, no cap 🧚 and for the cute sign-off: this came from the source tree at ./drivers/firmware/efi, dated October 2026 — periodt 💖🦋🌸

📦 where this page comes from