Make the kernel stack movable

[Darksecond]

Right now the kernel stack is always fixed in memory. If I want to make my kernel higher-half the kernel will need to move. This can be done by providing a custom linker script to the kernel target. This works fine. The stack that is setup by the bootloader however is always fixed in memory and will not move with the kernel.

I suggest making the stack location configurable like the physical memory offset already is. A more elegant solution would be to switch to an offset and automatically calculate the stack location.

[phil-opp]

Thank you for opening this issue!

I suggest making the stack location configurable like the physical memory offset already is. A more elegant solution would be to switch to an offset and automatically calculate the stack location.

I completely agree! I think it's best to support both variants: Dynamically calculate a sensible stack location by default and allow the user to override it through an environment variable.

I don't have the time to implement it myself right now, but I'd be happy to merge a pull request. Adding the environment variable can be done as in #58. For the dynamic calculation, I think the easiest way is something like the following (in pseudo code):

struct UsedLevel4Entries {
    entry_state: [bool; 512], // whether an entry is in use by the kernel
}

impl UsedLevel4Entries {
    fn get_free_entry(&mut self) -> Page<Size1GiB> {
        let entry = self.iter_mut().find(|b| b == false).unwrap();
        entry.set(true);
        entry.page();
    }
}

fn used_level_4_entries(kernel_elf: &KernelElfFile) -> UsedLevel4Entries {
    let mut used = UsedLevel4Entries { entry_state: [false; 512], };
    for program_segment in kernel_elf {
        for level_4_page in program_segment.level_4_page_range() {
            used[level_4_page.index()] = true;
        }
    }
    used
}

Then we can use get_free_entry for selecting a free level 4 entry for the kernel stack, the physical memory offset, the recursive mapping, and the boot info.

[64]

Going to take a stab at this at some point over the next few days

[64]

I have a minimal working version which does most of these things.

I think ideally we should avoid taking up four different p4 entries, if possible. Kernel stack and boot info can definitely be put in the same entry.

It would also be good to pass the kernel some kind of structure which can be used to easily unmap the boot info and bootloader mappings when the user wishes, and I think this might be a good opportunity to do it.

[phil-opp]

@64 Sounds good!

[64]

Note: I am planning to document this when I write up a guide on making higher-half kernels, which should be in the next week or so (but for now this is usable through the BOOTLOADER_KERNEL_STACK_ADDRESS environment variable).