[GSoC 2026] Approach for kexec/kload Implementation

Development OS
1

Hi Haiku Development team,

I was reviewing the GSoC project list and am very interested in Haiku’s proposal for implementing kexec (and potentially kload). I’ve spent some time looking into the architecture and wanted to share my initial understanding of the implementation strategy to see if I am on the right track.

Here is my current mental model and proposed approach:

  • The primary goal of kexec is to bypass the standard bootloader and BIOS/UEFI firmware phases, loading a new kernel image directly from the currently running one, while giving the new kernel the illusion of a fresh boot.

  • To safely load the target kernel binary and avoid memory fragmentation issues, I plan to allocate discrete 4KB pages (explicitly marked to prevent swapping). The host kernel will create an array of these physical addresses and pass it to the kexec trampoline (should I load trampoline as part of the kernel or as a separate module?).

  • The trampoline code will be responsible for parsing this address array, copying the target kernel fragments to their correct contiguous physical locations, and ensuring the hardware/device state is completely clean. It will then replicate the necessary bootloader hand-off sequence before jumping to the new kernel.

  • For the initial implementation, kexec can simply pass the existing host kernel’s arguments to the target kernel. As the project progresses, this will be expanded to accept and parse custom command-line arguments via user-space tools.

I would love to get your feedback on this initial high-level approach. Are there any Haiku-specific quirks regarding device teardown or the bootloader sequence that I should investigate next?

Best regards,
My Bad 2

1 Like
2

hi @mybad2,
i am also contributor like you interested in this project kexec, so korli sent github links to me regarding kexec, i’ll sent you can read and understand implemention.

if there is anything to ask specific to kexec contact @korli.

Best regards,

Pavan

2 Likes
3

Hello and welcome!

Yes, one special thing about Haiku’s kernel is that it expects the bootloader to do a lot of the hardware setup work. In particular, it expects to start with the MMU already enabled and a specific memory layout (the exact layout depends on the CPU architecture), and all boot peripherals (such as framebuffer, debug UART, …) already accessible.

I don’t know if that makes it easier or harder, but in any case it is a bit different from how things would be done in Linux, where the kernel would expect to do this early work on its own.

I will let korli comment if he has more details, as he probably thought about it more than I did :slight_smile:

1 Like
4

Oh, thanks for the information. I’ll try to get in touch with @korli

Best of Luck

5

a specific memory layout (the exact layout depends on the CPU architecture)

If the memory layout (memmap ig?) setup is done by the bootloader then we can just pass on memory layout from the host kernel to the target.

6

Looks like someone else may be interested also: (GSOC - 2026) new contributor - Interested project: kexec system feature - #11 by PulkoMandy

BTW, if I understand correctly, Linux kexec now supports EFI. This may be the easiest way to implement kexec anyway, and then the standard EFI loader can be used to start a new kernel.