Repository navigation
page allocator: support allocating pages within an address range - #970
kevinaboos merged 8 commits into
Conversation
aarch64: reserve 128MiB of virtual address space for executable text sections that is contiguous with the base kernel image's .text section.
Only issue is that deallocation isn't behaving as expected? for ex, an app crate's text sections should be freed after the app is finished executing and its crate has been unloaded, but that doesn't seem to be happening. Running `hello` twice in a row should use the same .text pages for both, but the second invocation is not re-using the .text pages from the first invocation.
kevinaboos
changed the title
|
@tsoutsman @NathanRoyer this isn't yet ready to merge (still has extra log statements and such), but the logic should be complete. I've tested it every way I can think of, but am still looking for reviews just to check the logic/math since it's such a core subsystem. Always helps to have an extra set of eyes on things, thanks! |
NathanRoyer
left a comment
NathanRoyer
left a comment
There was a problem hiding this comment.
I can confirm nothing seems weird here (I spent extra time in find_any_chunk to make sure that function was good).
Things I would change but you don't have to:
- this file seems to use hard tabs for some reason
- explicit imports were replaced with wildcard imports :(
- some warn! calls look like debugging statements, dunno if you want to keep them
Much appreciated!
Oh weird, I'll look at that in another PR.
Yeah, I can do this. That's just me being lazy temporarily.
Indeed, will remove before merging. |
tsoutsman
left a comment
tsoutsman
left a comment
There was a problem hiding this comment.
A potential way to simplify this in the future would be to move UPCOMING_PAGE_TABLE_RECURSIVE_P4_INDEX and RECURSIVE_P4_INDEX to the last entries in the page table so we can just chop off the last two pages rather than allocating around them.
yes indeed, i plan to do something similar to this once we refactor the heap a bit. We can't actually use entry 511, but we can use two contiguous entries like 509 and 510 instead of 508 and 510 like we have now. |
* Currently this is only used for allocating pages for new executable .text sections on aarch64, which itself is a workaround to enable runtime loading of crates (see #940). * Based on the limitations of aarch64's ISA (branch instructions), we reserve 128MiB of virtual address space for this purpose. * This 128MiB region is for executable .text sections only, and is contiguous with the base kernel image's .text section. * This is available but not used by default on x86_64 yet. e2806aa
…seus-os#970) * Currently this is only used for allocating pages for new executable .text sections on aarch64, which itself is a workaround to enable runtime loading of crates (see theseus-os#940). * Based on the limitations of aarch64's ISA (branch instructions), we reserve 128MiB of virtual address space for this purpose. * This 128MiB region is for executable .text sections only, and is contiguous with the base kernel image's .text section. * This is available but not used by default on x86_64 yet.
…seus-os#970) * Currently this is only used for allocating pages for new executable .text sections on aarch64, which itself is a workaround to enable runtime loading of crates (see theseus-os#940). * Based on the limitations of aarch64's ISA (branch instructions), we reserve 128MiB of virtual address space for this purpose. * This 128MiB region is for executable .text sections only, and is contiguous with the base kernel image's .text section. * This is available but not used by default on x86_64 yet. e2806aa
This is only needed on aarch64 for a workaround to allow #940 to work.
Currently, based on the needs of aarch64, we reserve 128MiB of virtual address space for executable text sections. This region is contiguous with the base kernel image's .text section.