On 05.06.2025 14:20, Marek Marczykowski-Górecki wrote: > On Thu, Jun 05, 2025 at 02:02:21PM +0200, Jan Beulich wrote: >> On 05.06.2025 13:16, Andrew Cooper wrote: >>> The format of the buildid is a property of the binary, not a property of how >>> it was loaded. This fixes buildid recognition when starting xen.efi from >>> it's >>> MB2 entrypoint. >>> >>> Suggested-by: Ross Lagerwall <ross.lagerw...@citrix.com> >>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >> >> I'll pick this up without a Fixes: tag, but I think it ought to have one. (I >> didn't check whether MB2 or build-id support came later, hence introducing >> the >> issue.) >> >>> --- a/xen/common/version.c >>> +++ b/xen/common/version.c >>> @@ -203,8 +203,11 @@ void __init xen_build_init(void) >>> rc = xen_build_id_check(n, sz, &build_id_p, &build_id_len); >>> >>> #ifdef CONFIG_X86 >>> - /* Alternatively we may have a CodeView record from an EFI build. */ >>> - if ( rc && efi_enabled(EFI_LOADER) ) >>> + /* >>> + * xen.efi built with a new enough toolchain will have a CodeView >>> record, >>> + * not an ELF note. >>> + */ >>> + if ( rc ) >> >> Instead of dropping the efi_enabled(), I think you want to replace EFI_LOADER >> by EFI_BOOT. > > Part of the motivation for MB2 entry point in xen.efi is using the > same binary in all boot modes, including legacy boot - in which case > none of EFI_* checks would be appropriate here. The grub series adds > support for loading PE binaries, and IIUC it isn't tied to booting via > EFI.
"The grub series" being which one? I didn't know xen.efi's non-EFI MB2 entry point could be used; instead I was under the impression that someone was having (half?) a patch eliminating the MB data from xen.efi, as being dead code. Jan
