The HAL memory API tries to model an abstract version of a sensible architecture’s virtual memory model. It should be suitable for implementations for x86_64, AArch64, and paged RISC-V.
It assumes two address spaces, the physical and the virtual (each of which have an address type). Physical
memory is split into frames, while virtual memory is split into pages. A
Mapper can be used to map parts of
the virtual address space into the physical address space.
FrameAllocatorthat can’t actually allocate or free frames. Useful if you need to pass a
FrameAllocatorto something for testing, but it’ll never actually try to allocate.
- Defines the permissions for a region of memory. Used both for abstract regions of memory (e.g. entries in a memory map) and as a architecture-common representation of paging structures.
- Represents a physical address. If the target architecture has any requirements for valid physical addresses, they are always enforced.
- Represents a virtual address. On architectures that have extra requirements for canonical virtual addresses (e.g. x86_64 requiring correct sign-extension in high bits), these requirements are always enforced.
FrameAllocatoris used to interact with a physical memory manager in a platform-independent way. Methods on
&selfand so are expected to use interior-mutability through a type such as
Mutexto ensure safe access. This allows structures to store a reference to the allocator, and deallocate memory when they’re dropped.
- This trait is implemented by a number of marker types, one for each size of frame and page. Different size types are defined depending on the target architecture.
PageTableallows the manipulation of a set of page-tables.