Re: [PATCH v4 21/23] x86/slaunch: support EFI boot

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/08/2026 2:09 pm, Sergii Dmytruk wrote:
> When running on an EFI-enabled system, Xen needs to have access to Boot
> Services in order to initialize itself properly and reach a state in
> which a dom0 kernel can operate without issues.
>
> This means that DRTM must be started in the middle of Xen's
> initialization process.  This effect is achieved via a callback into
> a TrenchBoot-enabled bootloader (GRUB) which is responsible for
> initiating DRTM and continuing Xen's initialization process.  The latter
> is done by branching in Slaunch entry point on a flag to switch back
> into long mode before calling the same function which Xen would execute
> as the next step without DRTM.
>
> Signed-off-by: Krystian Hebel <krystian.hebel@xxxxxxxxx>
> Signed-off-by: Sergii Dmytruk <sergii.dmytruk@xxxxxxxxx>
> ---
>
> Notes:
>     v4: -DXEN_BUILD_EFI => -DXEN_BUILD_EFI=1
>     v4: use CONFIG_SLAUNCH
>     v4: use pointers to `const` SLRT and TXT heap data
>     v4: use container_of()
>     v4: take updates to `struct boot_module` into account
>     v4: now UEFI_SLR_TABLE_GUID is defined here in efi/boot.c
>
>  .gitignore                                    |   1 +
>  .../eclair_analysis/ECLAIR/out_of_scope.ecl   |   1 +
>  docs/hypervisor-guide/x86/how-xen-boots.rst   |  14 +-
>  xen/arch/x86/Makefile                         |  12 +-
>  xen/arch/x86/boot/head.S                      | 124 +++++++++++++++++
>  xen/arch/x86/boot/x86_64.S                    |  14 +-
>  xen/arch/x86/efi/efi-boot.h                   |  94 ++++++++++++-
>  xen/arch/x86/efi/fixmlehdr.c                  | 127 ++++++++++++++++++
>  xen/arch/x86/slaunch.c                        |  75 ++++++++++-
>  xen/common/efi/boot.c                         |   6 +
>  xen/common/efi/runtime.c                      |   1 +
>  xen/include/xen/efi.h                         |   1 +
>  12 files changed, 455 insertions(+), 15 deletions(-)
>  create mode 100644 xen/arch/x86/efi/fixmlehdr.c
>
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 8dbb76a3a0..4f7db9420e 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -89,6 +89,7 @@ extra-y += xen.lds
>  
>  hostprogs-y += boot/mkelf32
>  hostprogs-y += efi/mkreloc
> +hostprogs-y += efi/fixmlehdr
>  
>  $(obj)/efi/mkreloc: HOSTCFLAGS += -I$(srctree)/include
>  
> @@ -123,6 +124,11 @@ $(TARGET): $(TARGET)-syms $(efi-y) $(obj)/boot/mkelf32
>  
>  CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
>  
> +# Expose this build flag as a macro when compiling assembly files.
> +ifeq ($(XEN_BUILD_EFI),y)
> +XEN_AFLAGS += -DXEN_BUILD_EFI=1
> +endif
> +
>  $(TARGET)-syms: $(objtree)/prelink.o $(obj)/xen.lds
>       $(objtree)/tools/symbols $(all_symbols) --empty > $(dot-target).0.S
>       $(MAKE) $(build)=$(@D) $(dot-target).0.o
> @@ -196,7 +202,7 @@ note_file_option ?= $(note_file)
>  extra-$(XEN_BUILD_PE) += efi.lds
>  ifeq ($(XEN_BUILD_PE),y)
>  $(TARGET).efi: $(obj)/efi/relocs-dummy.o $(obj)/efi/relocs-empty.o 
> $(obj)/efi/mkreloc
> -$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds
> +$(TARGET).efi: $(objtree)/prelink.o $(note_file) $(obj)/efi.lds 
> $(obj)/efi/fixmlehdr
>  ifeq ($(CONFIG_DEBUG_INFO),y)
>       $(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug 
> info from $(@F)"
>  endif
> @@ -230,6 +236,10 @@ endif
>       $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T $(obj)/efi.lds $< 
> $(obj)/efi/relocs-empty.o \
>             $(dot-target).2r.o $(dot-target).2s.o $(orphan-handling-y) \
>             $(note_file_option) -o $@
> +ifeq ($(CONFIG_SLAUNCH),y)
> +     # update entry point's address by taking image offset into account
> +     $(obj)/efi/fixmlehdr $@ $(XEN_IMG_OFFSET)
> +endif
>       $(NM) -pa --format=sysv $@ \
>               | $(objtree)/tools/symbols --all-symbols --xensyms --sysv 
> --sort \
>               > $@.map

This has collided completely with changes to how we link Xen.

Also, as a general rule we don't like post-processing the binary like
this.  What's the real problem trying to be solved?  Is it really just
the address in one field of the MLE header?  If so, why can't this be
fixed by adding the offset at build time?

~Andrew