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

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

On Mon, 17 Aug 2026, at 17:08, Leif Lindholm wrote:
> On Mon, Aug 17, 2026 at 14:00:16 +0300, Ard Biesheuvel wrote:
>> >> > 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.
>> >
>> > It's an internal business in the topic under discussion, but if we
>> > were to change it, that would mean updating booting.rst, which I
>> > consider an ABI.
>> >
>> 
>> But not an external ABI. It documents specifically how the EFI stub
>> interfaces with the kernel proper. This might change at any point,
>> without any obligation whatsoever to remain compatible with the
>> previous method.
>
> So you're saying if the kernel proper decides to use x1 for something
> else, we'll move to x2?
>
> I agree that in the context of how the stub calls the kernel proper,
> this is not ABI, but x1 is one of the registers currently marked as
> "reserved for future use" in booting.rst. So it feels weird for me to
> allocate one of those registers for this internal use then not mention
> it.
>

Whether we mention it or not is irrelevant: the only thing that matters
is that this allocation is not something that OS loaders other than the
EFI stub are able to rely upon, given that EFI boot on arm64 requires
booting via the stub (except for Xen dom0).

> In that case, couldn't we instead pick a register outside of the
> reserved ones?
>

It has to be a reserved one, given that the state of other registers is
unspecified at boot. Otherwise, we'd have to reason about whether a non-zero
value is accidental, or represents a physical address that we can map and
dereference, which is needed even to check the system table's magin

>> ...
>> >> > Minor bikeshedding below.
>> >> >
>> >> >> @@ -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?
>> >
>> > Apologies, I may have commented confusingly - my comment was about the
>> > else branch:
>> >
>> > +
>> > +                       bm = early_memremap_ro(memmap, sizeof(*bm));
>> > +                       if (!bm) {
>> > +                               pr_err("Cannot remap EFI boot memory map\n");
>> > +                               return 0;
>> > +                       }
>> > +
>> > +                       mm->phys_map            = memmap + sizeof(*bm);
>> > +                       mm->size                = bm->map_size;
>> > +                       mm->desc_size           = bm->desc_size;
>> > +                       mm->desc_version        = bm->desc_ver;
>> > +
>> > +                       early_memunmap(bm, sizeof(*bm));
>> >
>> > So to restate - this function is called from efi_init():
>> > ---
>> >         /* Grab UEFI information placed in FDT by stub */
>> >         efi_system_table = efi_get_fdt_params(&data);
>> >         if (!efi_system_table)
>> >                 return;
>> > ---
>> >
>> > Before this set, this function called get_fdt_params() indeed gets
>> > "params" from a device tree. After this set, this function gets params
>> > from a device tree in some instances, and not in others.
>> > Which feels suboptimal.
>> >
>> > We could rename the function, but then there's still DT-unrelated
>> > code held in fdtparams.c.
>> >
>> > If we go down the route of passing the system table in x1 on boot,
>> > then I guess the effect of assigning efi_system_table will already be
>> > broken out. But should we then split the mm struct initialisation into
>> > separate DT and config table helper functions?
>> >
>> 
>> Not disagreeing but I think it is fine to leave it as I suggested at this
>> point.
>> 
>> Some additional work is needed to get rid of linux,uefi-boot-memmap
>> entirely, and until that happens, passing the EFI system table via
>> X1 and linux,uefi-boot-memmap via DT is not a huge improvement.
>> 
>> linux,uefi-boot-memmap is needed when SetVirtualAddressMap() is called
>> [with a non-1:1 mapping], as the EFI system table contains a remapped
>> address of the config table array in that case.
>
> Of course, the devil on my shoulder suggests the stub could always
> add an address fixup handler for the config table too...
>

What is an address fixup handler? We cannot change this value back,
as that might break the runtime services.