Initial MMU support #4465

Ioan-Cristian · 2025-06-12T14:08:18Z

This pull request revamps the memory management system completely. The goals of the new memory management are:

Make Tock MMU-capable
Preserve compatibility with MPU architectures
Improve memory safety through abstractions types
Extract any non-architecture specific logic from arch crates to the kernel crate
Same kernel runs on different architectures: MMU-capable, MPU-capable or without memory protection
No overhead for MPU architectures
Configurable memory granule
No changes required for chips and capsule crates.

This pull request was tested by running libtock-rs applications on Raspberry Pi Pico, QEMU RISC-V 32-bit and QEMU x86.

This PR is currently blocked by:

This PR should be labeled as blocked until the previous two PRs are merged.

This pull request still needs to clarify the following points:

The current implementation supports only two regions for each process: PROG and RAM. This breaks IPC support (unusued in libtock-rs). A future patch will address this issue.
ARMv*-M architectures have limited capabilities due to hardware restrictions: if the region is not a power a two, then only the greatest power of two smaller than the region size is covered, and only if the start of the region is properly aligned. A better algorithm that makes use of subregions could soft the size restriction.
Broken process restart. ProcessStandard::create() needs to be refactored in several functions that can be reused by ProcessStandard::reset().
Currently, there is some overhead for MPU architectures:
- ASIDs are useless. They could be simply be (). Impossible to implement since the kernel needs &dyn Process, which in turn means that Process needs to be object-safe.
- Userspace virtual pointer -> kernel virtual pointer is still performed on allows. This could be a no-op.
The granule is currently hard-coded as a 4KiB page. Impossible to make it generic since the kernel needs dyn Process, which in turn means that Process needs to be object-safe.
Kernel address space should be mapped at higher addresses on MMU-capable architectures to allow the entire low virtual address space to processes. This feature is architecture dependent. A solution to cover both MPU-capable and MMU-capable architectures needs to be found.