Bootloader hardcodes 0x10_0000 as available, which can cause problems
Currently, the EFI bootloader is hardcoding the physical address 0x10_0000 (1 MiB) as a target to move the kernel to. This is unfortunately not guaranteed to work; in fact, QEMU when using the default QEMU make target, some addresses within offsets 0x80_0000 to 0x150_0000 are reserved for ACPI NVS (i.e. not just storing reclaimable tables, but possibly registers) and boot services data (which from my understanding could store crucial structures, like page tables or descriptor tables)..
This only allows kernels up to 8 MiB large in this case, which makes the regular
make qemu_efi work, but makes the
make qemu_iso_efi target triple fault (which again could be caused by something else, but given that the kernel in that case gets as large as 200 MiB, it will overwrite the reserved regions).
What I suggest we can do to fix this, is to be more flexible about where the kernel can be located in the physical address space. Since KERNEL_OFFSET is a hardcoded constant in the kernel binary, it must be contiguous in virtual address space. We should thus let the kernel reserve itself in the allocator structures, and allow the bootloader to potentially load it non-contiguously in physical address space. Otherwise we could force the bootloader to load the kernel contiguously in the physical address space, but allow it to be relocated anywhere physically (i.e. not hardcoded to 1 MiB).