Re: [PATCH v3 2/5] mm/memory-failure: libstub: install the poisoned-memory EFI table

[Kiryl Shutsemau <kas@kernel.org>]

On Wed, Aug 26, 2026 at 05:03:53AM -0700, Breno Leitao wrote:
> A EFI config table can only be installed while boot services are still
> up, so the stub has to create it; the running kernel can only flip bits
> in a table that already exists.
> 
> Size the bitmap from the top of usable RAM, which efi_get_ram_top()
> works out by walking the UEFI memory map, since the stub has no max_pfn.
> Bit N covers unit N counting from address 0, so the table tracks
> max_pfn. Memory the firmware hot-adds later sits above it and is not
> carried across a kexec.
> 
> One table has to serve every architecture, so efi_get_ram_top() takes
> the union of the memory types they turn into RAM: what setup_e820() maps
> to E820_TYPE_RAM on x86, plus the EFI_ACPI_RECLAIM_MEMORY and
> EFI_PERSISTENT_MEMORY that is_usable_memory() accepts on arm64. Sizing
> wide only costs bitmap bytes; sizing narrow silently drops the records
> for every frame above the top.

x86 and ARM doesn't seem to agree what RAM is. On x86 it is by ->type
and on ARM it is by ->attribute (anything WB/WC/WT).

is_usable_memory() only decides nomap. Everything is_memory() lets in
lands in memblock.memory, and max_pfn is PFN_DOWN(memblock_end_of_DRAM()),
so the top of RAM there can be a type that is not on your list.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov