Revamped memory management system

[Ioan-Cristian]

Pull Request Overview

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

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

Testing Strategy

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

TODO or Help Wanted

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.

Documentation Updated

• Add documentation comments on each public method.

Formatting

• Ran make prepush.