Re: [PATCH 2/3] efi: Pass EFI boot memmap struct address to core kernel

["Ard Biesheuvel" <ardb@kernel.org>]

On Fri, 14 Aug 2026, at 18:16, Leif Lindholm wrote:
> On Thu, Aug 13, 2026 at 09:45:09 +0200, Ard Biesheuvel wrote:
>> The EFI stub already passes a struct efi_boot_memmap populated with the
>> information of the EFI memory map as a configuration table, and so
>> passing the physical address, size, descriptor size and descriptor
>> version via 4 different DT properties is kind of redundant.
>> 
>> Instead, pass the physical address of this struct in memory so that the
>> kernel can just retrieve the values directly.
>> 
>> Unfortunately, the scheme with four separate properties is boot ABI for
>> Xen, and so this needs to remain supported.
>
> To clarify, you mean boot ABI when running under Xen?
>

Yes. We've allowed Xen dom0 to omit the EFI stub entirely, and boot the
kernel proper in EFI mode, passing the EFI system table and memory map
addresses via these special DT properties.

>> But for the EFI stub itself,
>> this is just an internal ABI that can be modified.
>
> Hmm...
>
> So this leaves only three properties that cannot be derived from the
> System Table:
> - The System Table address itself
> - kaslr-seed
> - bootargs
>
> The latter two could also be given the config table treatment.
>

The latter two are generic boot ABI for the arm64 kernel, and there
is no need to treat them differently for EFI boot. Note that we also
support passing the initrd directly via DT when doing EFI boot, rather
than via the EFI specific device path.

> Is it time to update the boot ABI to say x0 will hold the physical
> address of "device tree blob (dtb) or EFI System Table in system RAM"?
> They can be distinguished by 0xd00dfeed / "IBI SYST".
>

Let's avoid 'boot ABI' here, given that we are talking about an internal
interface between the EFI stub and the kernel proper.

This internal interface uses DT under the hood, even on ACPI platforms,
because it simplifies the early boot code. I don't think we should change
this.

Also, the DT provided by the bootloader (if any) may differ from the one
passed by the EFI stub, and so discovering the DT from the EFI system
table is not straight-forward - they are not the same, and making them
the same may have unintended side effects.
 
> The use of a generated DT when none was provided by firmware has led
> to both confusion and shenanigans, and might be nice to get rid of?
>

I don't disagree with that. But that would imply adding new code to the
early startup code doing command line parsing and KASLR randomization to
reason about whether these assets are passed via DT or via some other means.

What would make sense imo is to pass the EFI system table address via X1
when doing EFI boot, so we don't have to get anything at all from the DT.

> Either way, it would be nice to get rid of all four of the
> linux,uefi-mmap nodes if they're now completely redundant.
>

Indeed.

> Minor bikeshedding below.
>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> ---
>>  Documentation/arch/arm/uefi.rst    | 10 +----
>>  drivers/firmware/efi/fdtparams.c   | 39 ++++++++++++++++---
>>  drivers/firmware/efi/libstub/fdt.c | 40 ++------------------
>>  3 files changed, 37 insertions(+), 52 deletions(-)
>> 
>> diff --git a/Documentation/arch/arm/uefi.rst b/Documentation/arch/arm/uefi.rst
>> index 2b7ad9bd7cd2..c19cf3720f27 100644
>> --- a/Documentation/arch/arm/uefi.rst
>> +++ b/Documentation/arch/arm/uefi.rst
>> @@ -54,17 +54,9 @@ Name                        Type     Description
>>  ==========================  ======   ===========================================
>>  linux,uefi-system-table     64-bit   Physical address of the UEFI System Table.
>>  
>> -linux,uefi-mmap-start       64-bit   Physical address of the UEFI memory map,
>> +linux,uefi-boot-memmap      64-bit   Physical address of a struct efi_boot_memmap
>>                                       populated by the UEFI GetMemoryMap() call.
>>  
>> -linux,uefi-mmap-size        32-bit   Size in bytes of the UEFI memory map
>> -                                     pointed to in previous entry.
>> -
>> -linux,uefi-mmap-desc-size   32-bit   Size in bytes of each entry in the UEFI
>> -                                     memory map.
>> -
>> -linux,uefi-mmap-desc-ver    32-bit   Version of the mmap descriptor format.
>> -
>>  kaslr-seed                  64-bit   Entropy used to randomize the kernel image
>>                                       base address location.
>>  
>> diff --git a/drivers/firmware/efi/fdtparams.c b/drivers/firmware/efi/fdtparams.c
>> index b815d2a754ee..a54a76a6aaeb 100644
>> --- a/drivers/firmware/efi/fdtparams.c
>> +++ b/drivers/firmware/efi/fdtparams.c
>> @@ -10,22 +10,30 @@
>>  
>>  #include <linux/unaligned.h>
>>  
>> +#include <asm/early_ioremap.h>
>> +
>>  enum {
>>  	SYSTAB,
>> +	MEMMAP,
>> +#ifdef CONFIG_XEN
>>  	MMBASE,
>>  	MMSIZE,
>>  	DCSIZE,
>>  	DCVERS,
>> +#endif
>>  
>>  	PARAMCOUNT
>>  };
>>  
>>  static __initconst const char name[][22] = {
>>  	[SYSTAB] = "System Table         ",
>> +	[MEMMAP] = "Boot Memory Map      ",
>> +#ifdef CONFIG_XEN
>>  	[MMBASE] = "MemMap Address       ",
>>  	[MMSIZE] = "MemMap Size          ",
>>  	[DCSIZE] = "MemMap Desc. Size    ",
>>  	[DCVERS] = "MemMap Desc. Version ",
>> +#endif
>>  };
>>  
>>  static __initconst const struct {
>> @@ -49,10 +57,7 @@ static __initconst const struct {
>>  		.path = "/chosen",
>>  		.params = {	//  <-----------26----------->
>>  			[SYSTAB] = "linux,uefi-system-table",
>> -			[MMBASE] = "linux,uefi-mmap-start",
>> -			[MMSIZE] = "linux,uefi-mmap-size",
>> -			[DCSIZE] = "linux,uefi-mmap-desc-size",
>> -			[DCVERS] = "linux,uefi-mmap-desc-ver",
>> +			[MEMMAP] = "linux,uefi-boot-memmap",
>>  		}
>>  	}
>>  };
>> @@ -84,17 +89,20 @@ static int __init efi_get_fdt_prop(const void *fdt, int node, const char *pname,
>>  u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm)
>>  {
>>  	const void *fdt = initial_boot_params;
>> -	unsigned long systab;
>> +	unsigned long systab, memmap;
>>  	int i, j, node;
>>  	struct {
>>  		void	*var;
>>  		int	size;
>>  	} target[] = {
>>  		[SYSTAB] = { &systab,		sizeof(systab) },
>> +		[MEMMAP] = { &memmap,		sizeof(memmap) },
>> +#ifdef CONFIG_XEN
>>  		[MMBASE] = { &mm->phys_map,	sizeof(mm->phys_map) },
>>  		[MMSIZE] = { &mm->size,		sizeof(mm->size) },
>>  		[DCSIZE] = { &mm->desc_size,	sizeof(mm->desc_size) },
>>  		[DCVERS] = { &mm->desc_version,	sizeof(mm->desc_version) },
>> +#endif
>>  	};
>>  
>>  	BUILD_BUG_ON(ARRAY_SIZE(target) != ARRAY_SIZE(name));
>> @@ -115,6 +123,9 @@ u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm)
>>  		for (j = 0; j < ARRAY_SIZE(target); j++) {
>>  			const char *pname = dt_params[i].params[j];
>>  
>> +			if (pname[0] == '\0')
>> +				continue;
>> +
>>  			if (!efi_get_fdt_prop(fdt, node, pname, name[j],
>>  					      target[j].var, target[j].size))
>>  				continue;
>> @@ -123,8 +134,24 @@ u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm)
>>  			pr_err("Can't find property '%s' in DT!\n", pname);
>>  			return 0;
>>  		}
>> -		if (dt_params[i].paravirt)
>> +		if (IS_ENABLED(CONFIG_XEN) && dt_params[i].paravirt) {
>>  			set_bit(EFI_PARAVIRT, &efi.flags);
>> +		} else {
>
> This condition branch doesn't in fact have anything to do with the fdt.
> Should it still live in fdtparams.c?
>

I don't follow. The EFI_PARAVIRT flag is set based on whether we are 
using the generic or the Xen-specific set of DT properties. What would
be a better place to decide this?