When a PIC kernel is located in higher half, we currently try to allocate 33554177 entries in the level 4 page table, which of course fails. This is the reason that we currently use the static relocation model for our higher half test:
|
"relocation-model=static", # pic in higher half not supported yet |
I think the issue is in these lines:
|
// Find the highest virtual memory address and the biggest alignment. |
|
let load_program_headers = elf_file |
|
.program_iter() |
|
.filter(|h| matches!(h.get_type(), Ok(Type::Load))); |
|
let size = load_program_headers |
|
.clone() |
|
.map(|h| h.virtual_addr() + h.mem_size()) |
|
.max() |
|
.unwrap_or(0); |
|
let align = load_program_headers.map(|h| h.align()).max().unwrap_or(1); |
|
|
|
used_entries.get_free_address(size, align).as_u64() |
Looks like we only consider the end address for the size calculation, without taking the start address into account. I think we should be able to fix this by using the difference between the max and min address as size instead.
When a PIC kernel is located in higher half, we currently try to allocate 33554177 entries in the level 4 page table, which of course fails. This is the reason that we currently use the
staticrelocation model for our higher half test:bootloader/Cargo.toml
Line 87 in 4e2b8d7
I think the issue is in these lines:
bootloader/common/src/load_kernel.rs
Lines 64 to 75 in 4e2b8d7
Looks like we only consider the end address for the size calculation, without taking the start address into account. I think we should be able to fix this by using the difference between the max and min address as size instead.