On Tue, 12 Nov 2024 at 18:48, Simon Glass sjg@chromium.org wrote:
A bisect of Ubuntu 2022.04 boot-failure on qemu-x86_64 resulted in this patch. I am not sure how to investigate it.
The boot hangs at some point during booting of the install image, before the Ubuntu logo appears.
I will sent a series with a script showing how it is run.
This reverts commit a68c9ac5d8afc51c619c5d3e865fcf147bea90cb.
Signed-off-by: Simon Glass sjg@chromium.org
I did some digging into this issue, and it turns out that the revert is only masking the real issue. What this revert does is mark the memory region occupied by U-Boot as EFI_BOOT_SERVICES_CODE. The x86 kernel seems to mark memory regions other than EFI_{BOOT,RUNTIME}_SERVICES_CODE as not executable -- and this is precisely why this crash shows up only on x86. The actual cause of this issue is in the efi runtime functionality of U-Boot. The kernel is calling the SetVirtualAddressMap() runtime service function, and that seems to be calling some of the boot service code of U-Boot, which it shouldn't. We do not get the crash after disabling the ConvertPointer() and SetVirtualAddressMap() runtime functions.
-sughosh
lib/efi_loader/efi_memory.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c index d2f5d563f2a..c7400ec9854 100644 --- a/lib/efi_loader/efi_memory.c +++ b/lib/efi_loader/efi_memory.c @@ -809,6 +809,16 @@ static void add_u_boot_and_runtime(void) { unsigned long runtime_start, runtime_end, runtime_pages; unsigned long runtime_mask = EFI_PAGE_MASK;
unsigned long uboot_start, uboot_pages;unsigned long uboot_stack_size = CONFIG_STACK_SIZE;/* Add U-Boot */uboot_start = ((uintptr_t)map_sysmem(gd->start_addr_sp, 0) -uboot_stack_size) & ~EFI_PAGE_MASK;uboot_pages = ((uintptr_t)map_sysmem(gd->ram_top - 1, 0) -uboot_start + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;efi_add_memory_map_pg(uboot_start, uboot_pages, EFI_BOOT_SERVICES_CODE,false);#if defined(__aarch64__) /* -- 2.34.1