aarch64: dynamically map kernel code in early boot #1087
Labels
Comments
wkozaczuk
added a commit
that referenced
this issue
Mar 14, 2021
Until we implement #1087 to dynamically map kernel ELF located anywhere in physical memory, we always need to make sure that that the kernel_base is eqaul to kernel_vm_base in the makefile. So let us explicitly state this in rule in the makefile. The extra benefit is that it should be now a bit easier to build kernel for hypervisors that load kernel ELF in a place different than default QEMU one - 0x40080000. For example to build loader.img for firecracker it should be as easy as: pushd build/release.aarch64/ && rm -f loader.* arch/aarch64/arch-dtb.* core/elf.* core/mmu.* && popd \ && ./scripts/build -j$(nproc) image=native-example fs=rofs mode=release --create-disk kernel_base=0x80080000 ./scripts/firecracker.py -k build/release/loader.img -i build/release/disk.raw -c 2 Ideally at some point in future we could enhance the makefile to make it generate some sort of header file with variables like kernel_base and have it be included by source files (core/mmu.cc, etc) that depend on it. That way simply passing kernel_base parameter to the build command would automatically rebuilt all necessary sources without having to explicitly delete relevant object files which we have to do now. Signed-off-by: Waldemar Kozaczuk <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unlike x86_64, we do not have control where in physical memory the kernel code (loader.elf) will be loaded. On QEMU it gets loaded by its bootloader at
0x40080000, on Firecracker at0x80080000(1GB higher) which then is 1-1 mapped to virtual memory by the early boot page tables. So currently to run OSv on firecracker one has to manually changekernel_baseandkernel_vm_basein theMakefileand recompile/relink the kernel (more specifically 3 object files -core/mmu.o,core/elf.o,loader.oandloader.elfneed to be re-built).This is obviously not ideal as we would want to have a single version of loader.elf that could work on both QEMU and firecracker. To achieve that, we somehow have to dynamically calculate where
loader.elfgot loaded in physical memory and dynamically adjust (add/subtract the delta) to the portion of the early boot mapping. In general, we have to support non 1-1 mapping of the kernel code.The text was updated successfully, but these errors were encountered: