On 12/17/25 11:39, Ilias Apalodimas wrote:
Thanks Patrick,
On Wed, 17 Dec 2025 at 09:26, Patrick Rudolph
<[email protected]> wrote:
When FTRACE is enabled the EFI runtime will call the tracing functions
that are not marked as __efi_runtime and cause a kernel panic since
the functions have been previously unmapped by the kernel.
Resolve this issue by adding the 'notrace' attribute to '__efi_runtime'
attribute and thus disable tracing the EFI runtime. If required this
can be worked out latter.
What is the point of actually booting with a U-Boot binary with FTRACE
enabled? All your trace data will be lost.
Wouldn't it be preferable to error out at ExitBootServices() and
retrieve the trace?
The current implementation of FTRACE looks flawed. The trace buffer
should be allocated from LMB so that it cannot overwrite images or EFI data.
Best regards
Heinrich
So I agree with this. Fixing is just a matter of moving the missing
functions to the runtime section, but I don;t think it's worth it,
unless someone *really* wants to instrument runtime calls.
OTOH runtime calls in the OS are rare and very limited
Reviewed-by: Ilias Apalodimas <[email protected]>
TEST=Can boot a UEFI compatible linux OS on qemu-q35 when U-Boot was
built with FTRACE=1.
Signed-off-by: Patrick Rudolph <[email protected]>
---
include/efi_loader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 3e70ac07055..7a13c390cbe 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -66,7 +66,7 @@ struct bootflow;
*
* static __efi_runtime compute_my_table(void);
*/
-#define __efi_runtime __section(".text.efi_runtime")
+#define __efi_runtime __section(".text.efi_runtime") notrace
/*
* Call this with mmio_ptr as the _pointer_ to a pointer to an MMIO region
--
2.52.0