[PATCH] Revert "efi_memory: do not add U-Boot memory to the memory map"
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 ---
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__) /*
Hi Simon,
On Tue, 12 Nov 2024 at 15:18, 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.
Any idea if this is before or after ExitBootServices? The console prints some efi-stub calls before it jumps into the kernel. Unfortunately, those aren't preserved in a dmesg
I will sent a series with a script showing how it is run.
How can I reproduce this? Run the installer on QEMU on top of U-Boot? Is U-Boot compiled as an EFI app or not?
This reverts commit a68c9ac5d8afc51c619c5d3e865fcf147bea90cb.
In theory, the memory map should already be added by LMB. So instead of reverting this, it would make more sense to compare the memory map with/without the patch and see if something is missing from LMB
Thanks /Ilias
Signed-off-by: Simon Glass sjg@chromium.org
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
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
This seems to be an issue specific to the x86 architecture. The installation works on arm64 and riscv (confirmed by Heinrich) architectures. I checked the output of the EFI memory map with the above commit against the master branch, and the only difference is that with this revert, the EFI memory map has the u-boot memory region marked as EFI_BOOT_SERVICES_CODE, whereas without this commit, that region is marked as reserved. I need to look into this in more detail, but it would seem like the x86 kernel (or some efi stub code ?) is expecting some region of memory marked as EFI_BOOT_SERVICES_CODE, which is not the case for other architectures.
-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
Hi Sughosh
On Tue, 12 Nov 2024 at 20:46, Sughosh Ganu sughosh.ganu@linaro.org wrote:
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
This seems to be an issue specific to the x86 architecture. The installation works on arm64 and riscv (confirmed by Heinrich) architectures. I checked the output of the EFI memory map with the above commit against the master branch, and the only difference is that with this revert, the EFI memory map has the u-boot memory region marked as EFI_BOOT_SERVICES_CODE, whereas without this commit, that region is marked as reserved.
Hmm why? LMB is adding this with EFI_BOOT_SERVICES_CODE in lmb_map_update_notify(). Who's switching it to reserved? This is a pretty big change since the memory switches from reusable to reserved for the OS.
I need to look into this in more detail, but it would seem like the x86 kernel (or some efi stub code ?) is expecting some region of memory marked as EFI_BOOT_SERVICES_CODE, which is not the case for other architectures.
Not EFI_BOOT_SERVICES_CODE explicitly, probably just a reusable type of memory.
Cheers /Ilias
-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
On 11/13/24 12:28, Ilias Apalodimas wrote:
Hi Sughosh
On Tue, 12 Nov 2024 at 20:46, Sughosh Ganu sughosh.ganu@linaro.org wrote:
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 tried to replicate the problem with an Ubuntu 24.04.1 cloud image using a 6.8 kernel.
I see efi_exit_boot_services being reached but not efi_set_virtual_address_map. The kernel seems to be stuck in an endless loop in a virtual address range (0xffffffff????????).
The memory map looks wrong:
=> efidebug memmap Type Start End Attributes ================ ================ ================ ========== CONVENTIONAL 0000000000000000-00000000000a0000 WB RESERVED 00000000000a0000-00000000000f0000 WB ACPI RECLAIM MEM 00000000000f0000-00000000000f1000 WB RESERVED 00000000000f1000-0000000000100000 WB CONVENTIONAL 0000000000100000-000000003dca4000 WB BOOT DATA 000000003dca4000-000000003dca6000 WB RUNTIME DATA 000000003dca6000-000000003dca7000 WB|RT BOOT DATA 000000003dca7000-000000003dca8000 WB RUNTIME DATA 000000003dca8000-000000003dcca000 WB|RT BOOT DATA 000000003dcca000-000000003ecda000 WB RESERVED 000000003ecda000-000000003ece0000 WB ACPI RECLAIM MEM 000000003ece0000-000000003ed02000 WB RUNTIME DATA 000000003ed02000-000000003ed03000 WB|RT RESERVED 000000003ed03000-000000003ef1a000 WB RUNTIME CODE 000000003ef1a000-000000003ef1c000 WB|RT RESERVED 000000003ef1c000-0000000040000000 WB RESERVED 00000000e0000000-00000000f0000000 WB
The relocated U-Boot code should not be marked as EfiReservedMemoryType but as EfiServicesCode according to the UEFI specification.
The ACPI table is marked as EfiACPIReclaimMemory but I don't think memory in the BIOS memory range should be reclaimable. In the journal on my laptop I see
BIOS-provided physical RAM map BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
The e820 table is generated from the EFI memory map in setup_e820() of the Linux efi stub.
Best regards
Heinrich
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
This seems to be an issue specific to the x86 architecture. The installation works on arm64 and riscv (confirmed by Heinrich) architectures. I checked the output of the EFI memory map with the above commit against the master branch, and the only difference is that with this revert, the EFI memory map has the u-boot memory region marked as EFI_BOOT_SERVICES_CODE, whereas without this commit, that region is marked as reserved.
Hmm why? LMB is adding this with EFI_BOOT_SERVICES_CODE in lmb_map_update_notify(). Who's switching it to reserved? This is a pretty big change since the memory switches from reusable to reserved for the OS.
I need to look into this in more detail, but it would seem like the x86 kernel (or some efi stub code ?) is expecting some region of memory marked as EFI_BOOT_SERVICES_CODE, which is not the case for other architectures.
Not EFI_BOOT_SERVICES_CODE explicitly, probably just a reusable type of memory.
Cheers /Ilias
-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
On Wed, 13 Nov 2024 at 18:03, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/13/24 12:28, Ilias Apalodimas wrote:
Hi Sughosh
On Tue, 12 Nov 2024 at 20:46, Sughosh Ganu sughosh.ganu@linaro.org wrote:
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 tried to replicate the problem with an Ubuntu 24.04.1 cloud image using a 6.8 kernel.
I see efi_exit_boot_services being reached but not efi_set_virtual_address_map. The kernel seems to be stuck in an endless loop in a virtual address range (0xffffffff????????).
There are two issues to consider here. As Ilias had pointed out, I looked at why the U-Boot memory region was showing up as Reserved. And turns out that the e820 platform code defines efi_add_known_memory(), and this function seems to be overwriting memory regions' attribute with what gets set by the lmb code. So it turns out that the lmb code is setting the U-Boot memory region as EFI_BOOT_SERVICES_CODE indeed. But the install_e820_map() function in arch/x86/cpu/qemu/e820.c is setting the memory region occupied by U-Boot as reserved. This was getting masked earlier, as the add_u_boot_and_runtime() would set the U-Boot memory region with correct attributes. I think the correct fix would be to not mark the U-Boot memory regions as reserved by the e820 platform code.
In addition to the above, the x86 architecture specific efi stub code seems to require a region of memory with EfiBootServicesCode memory. But looking at the EFI spec, I do not see where this is mandated -- the spec only seems to mention that after the ExitBootServices() call, the EFI OS loader can treat EfiBootServices{Code,Data} as available free memory. Agreed that it would be better to mark the region of memory occupied by the firmware as EfiBootServicesCode, but then that would still not be strictly correct, as the U-Boot region contains code as well as data. So marking the region of memory occupied by U-Boot as EfiBootServicesData should not be an issue, at least based on what I understand. Moreover since this looks like a requirement only for the x86 architecture.
-sughosh
The memory map looks wrong:
=> efidebug memmap Type Start End Attributes ================ ================ ================ ========== CONVENTIONAL 0000000000000000-00000000000a0000 WB RESERVED 00000000000a0000-00000000000f0000 WB ACPI RECLAIM MEM 00000000000f0000-00000000000f1000 WB RESERVED 00000000000f1000-0000000000100000 WB CONVENTIONAL 0000000000100000-000000003dca4000 WB BOOT DATA 000000003dca4000-000000003dca6000 WB RUNTIME DATA 000000003dca6000-000000003dca7000 WB|RT BOOT DATA 000000003dca7000-000000003dca8000 WB RUNTIME DATA 000000003dca8000-000000003dcca000 WB|RT BOOT DATA 000000003dcca000-000000003ecda000 WB RESERVED 000000003ecda000-000000003ece0000 WB ACPI RECLAIM MEM 000000003ece0000-000000003ed02000 WB RUNTIME DATA 000000003ed02000-000000003ed03000 WB|RT RESERVED 000000003ed03000-000000003ef1a000 WB RUNTIME CODE 000000003ef1a000-000000003ef1c000 WB|RT RESERVED 000000003ef1c000-0000000040000000 WB RESERVED 00000000e0000000-00000000f0000000 WB
The relocated U-Boot code should not be marked as EfiReservedMemoryType but as EfiServicesCode according to the UEFI specification.
The ACPI table is marked as EfiACPIReclaimMemory but I don't think memory in the BIOS memory range should be reclaimable. In the journal on my laptop I see
BIOS-provided physical RAM map BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
The e820 table is generated from the EFI memory map in setup_e820() of the Linux efi stub.
Best regards
Heinrich
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
This seems to be an issue specific to the x86 architecture. The installation works on arm64 and riscv (confirmed by Heinrich) architectures. I checked the output of the EFI memory map with the above commit against the master branch, and the only difference is that with this revert, the EFI memory map has the u-boot memory region marked as EFI_BOOT_SERVICES_CODE, whereas without this commit, that region is marked as reserved.
Hmm why? LMB is adding this with EFI_BOOT_SERVICES_CODE in lmb_map_update_notify(). Who's switching it to reserved? This is a pretty big change since the memory switches from reusable to reserved for the OS.
I need to look into this in more detail, but it would seem like the x86 kernel (or some efi stub code ?) is expecting some region of memory marked as EFI_BOOT_SERVICES_CODE, which is not the case for other architectures.
Not EFI_BOOT_SERVICES_CODE explicitly, probably just a reusable type of memory.
Cheers /Ilias
-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
On Tue, Nov 12, 2024 at 06:18:30AM -0700, Simon Glass 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
You forgot to prefix this with "RFC" or "DEBUG" as we're not going to revert these changes, but we'll figure out why x86 doesn't behave like arm and riscv do and then Fixes the resulting commit. Thanks.
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
Hi Sughosh,
On Thu, 21 Nov 2024 at 00:53, Sughosh Ganu sughosh.ganu@linaro.org wrote:
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.
OK, so what is the solution here? Did you send a patch?
Regards, Simon
On Tue, 26 Nov 2024 at 21:09, Simon Glass sjg@chromium.org wrote:
Hi Sughosh,
On Thu, 21 Nov 2024 at 00:53, Sughosh Ganu sughosh.ganu@linaro.org wrote:
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.
OK, so what is the solution here? Did you send a patch?
I am trying to check if the installation can be done by disabling the ConvertPointer() and SetVirtualAddressMap() runtime service calls. If so, then I will send a patch which disables them temporarily till the actual issue is triaged and fixed. If the installation does not work without these runtime calls, I would say putting this change in with an explanation of what is happening (similar to the above explanation). Please give me some more days, and I will let you know. Thanks.
-sughosh
Regards, Simon
participants (5)
-
Heinrich Schuchardt -
Ilias Apalodimas -
Simon Glass -
Sughosh Ganu -
Tom Rini