copy more PML4 entries #466
Conversation
If there is more than 512 GiB of memory, we need to copy more than the first PML4 entry to access it. Similarly if the frame buffer is not in the address range covered by the first PML4 entry, we need to copy more entries in order to access it.
The bootloader maps some of the memory used by the kernel into its own address space as well. In order for that to work we must ensure that the bootloader doesn't already have memory mapped there. Mark regions that are likely to be used by the bootloader as unusable.
Just to clarify: Do you mean unusable for the bootloader or unusable in the memory map (i.e. affecting the kernel)? |
Thank you for the review!
We mark it as unusable for dynamic virtual memory space allocations for the kernel i.e. for mappings configured with |
|
Ah right. So when the UEFI firmware puts the framebuffer somewhere into the second PML4 entry, we won't use any address within that PML4 entry for dynamic kernel mappings? |
Yes, exactly. |
|
Ok, thanks for clarifying! Personally, I'm fine with this limitation for now. We can then try to make the used-tracking more precise in some future PR. I'm also looking into #465 currently. Which of the two approaches do you prefer? |
I like how #465 solves this problem without any limitations for the loaded kernel, but I think the code is much uglier/hackier. I agree that losing a pml4 is acceptable for now. I like your idea of making the used tracking more precise, this would allow us to use the less-hacky from this PR code but also minimize wasting virtual address space. |
|
Ok, then let's proceed with this PR. I don't mind the indirect memory access in #465, but I agree that the code seems a bit hacky in places (e.g. a separate translation step for each individual byte or the construction of an invalid |
If there is more than 512 GiB of memory, we need to copy more than the first PML4 entry to access it. Similarly if the frame buffer is not in the address range covered by the first PML4 entry, we need to copy more entries in order to access it. We also need to mark these PML4 entries as unusable when allocating virtual addresses for the kernel because the bootloader maps some of them into its own address space.
This is a much simpler solution to #462 than #465. The downside is that we mark some of the kernel's virtual address space as unusable when it doesn't technically need to be.
@Colepng Could you please also test this PR?
Supersedes #464
Closes #462