-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
restore demand paging PR + PC fixes #31564
Conversation
8da8e1b
to
e796dc2
Compare
This is only needed if the base address of SRAM doesn't have the same alignment as the base address of the virtual address space. Fix the calculations on X86 where this is the case. Signed-off-by: Andrew Boie <[email protected]>
These are needed on MMU systems and define where the kernel image resides in virtual memory at boot so that it may be memory-mapped. Signed-off-by: Andrew Boie <[email protected]>
We will use this to map the kernel instead of all RAM. The end of the kernel is always page-aligned, regardless of CONFIG_SRAM_REGION_PERMISSIONS as it must be mapped. Signed-off-by: Andrew Boie <[email protected]>
Add linker symbols corresponding to the start and end of the mapped Zephyr image. This is not used by the ARM arch yet, but is required to compile the core kernel MMU code. Signed-off-by: Andrew Boie <[email protected]>
_app_smem doesn't exist in this case. Signed-off-by: Andrew Boie <[email protected]>
We will need this to run on x86 with PC-like hardware. Signed-off-by: Andrew Boie <[email protected]>
Initialize the page frame ontology at boot and update it when we do memory mappings. Signed-off-by: Andrew Boie <[email protected]>
Allows applications to increase the data space available to Zephyr via anonymous memory mappings. Loosely based on mmap(). Signed-off-by: Andrew Boie <[email protected]>
Return the amount of physical anonymous memory remaining. Signed-off-by: Andrew Boie <[email protected]>
A more comprehensive solution would use E820 enumeration, but we are unlikely to ever care that much, as we intend to use demand paging on microcontrollers and not PC-like hardware. This is really to just prevent QEMU from crashing. Signed-off-by: Andrew Boie <[email protected]>
All RAM may not be mapped. Check the mapping for the main kernel image and the locore if it exists. Signed-off-by: Andrew Boie <[email protected]>
Implement runtime APIs for pinning, paging in, and evicting memory, as well as the page fault hook called from architecture code. Signed-off-by: Andrew Boie <[email protected]>
These get mapped to multiple virtual addresses and must be pinned. Signed-off-by: Andrew Boie <[email protected]>
Simple textbook Not Recently Used eviction algorithm. Signed-off-by: Andrew Boie <[email protected]>
Will be used by QEMU targets for testing purposes. Signed-off-by: Andrew Boie <[email protected]>
All arch_ APIs and macros are implemented, and the page fault handling code will call into the core kernel. Signed-off-by: Andrew Boie <[email protected]>
This target is specifically for simulating x86 micro- controllers with limited memory. Signed-off-by: Andrew Boie <[email protected]>
This will enable testing of the implementation until the critical set of pages is identified and known to the kernel. Signed-off-by: Andrew Boie <[email protected]>
Show we can measure free memory properly and map a page of anonymous memory, which has been zeroed and is writable. Signed-off-by: Andrew Boie <[email protected]>
More to be added, but for now show that we can map more anonymous memory than we physically have, and that reading/ writing to it works as expected. Signed-off-by: Andrew Boie <[email protected]>
Adding myself as original author. Signed-off-by: Andrew Boie <[email protected]>
Simple counter of number of successfully handled page faults by the core kernel. Signed-off-by: Andrew Boie <[email protected]>
Add remaining APIs in mem_manage.h even though not all have been promoted to public (yet). Signed-off-by: Andrew Boie <[email protected]>
If we evict enough pages to completely fill the backing store, through APIs like k_mem_map(), z_page_frame_evict(), or z_mem_page_out(), this will produce a crash the next time we try to handle a page fault. The backing store now always reserves a free storage location for actual page faults. Signed-off-by: Andrew Boie <[email protected]>
Until zephyrproject-rtos#31333 is resolved, the periodic timer in the eviction algorithm interacts with this test in such a way that the system deadlocks. Signed-off-by: Andrew Boie <[email protected]>
These are application facing and are prefixed with k_. Signed-off-by: Andrew Boie <[email protected]>
Some arches like x86 need all memory mapped so that they can fetch information placed arbitrarily by firmware, like ACPI tables. Ensure that if this is the case, the kernel won't accidentally clobber it by thinking the relevant virtual memory is unused. Otherwise this has no effect on page frame management. Signed-off-by: Andrew Boie <[email protected]>
These are all PC systems which have large amounts of memory which needs to be mapped at runtime (most are 2GB). Increase the address space size accordingly, adding an extra 8MB for mappings. The ACRN target has 8MB, give it 16MB of VM. Signed-off-by: Andrew Boie <[email protected]>
ACPI tables can lurk anywhere. Map all memory so they can be read. Signed-off-by: Andrew Boie <[email protected]>
e796dc2
to
9cc440e
Compare
Thanks @andrewboie! I've started HW testing, will post details soon. |
This unfortunately breaks EHL booting with SBL. Reverting to commit 3746ebc (i.e. right before this PR went in) makes it work again. |
Using
|
(edited - I was mixing 2MB and 2GB) I added some debug logs to the ACPI table code with the suspicion that something is outside of the mapped region, but it looks to me like everything is still within 2GB that's declared for the board:
Btw, I seem to be unable to increase the declared RAM amount from 2GB (even if I also increase KERNEL_VM_SIZE) - it results in some build errors. |
This PR: