metta-systems
/
vesper
1
1
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity

wip mmu plans

This commit is contained in:
Berkus Decker 2021-03-11 01:57:03 +02:00
parent a83905f90b
commit bb7316a7cb
1 changed files with 37 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
nucleus/src/arch/aarch64/memory/README.md
View File

@ -22,13 +22,15 @@ For more information please re-read.
---- ----
# Plan ## Plan
1. MMU tables - because we need separate memspaces for kernel and userspace 1. MMU tables - because we need separate memspaces for kernel and userspace
1a. Allocate initial page tables 1a. Allocate initial page tables
1b. Map over available RAM sensibly 1b. Map over available RAM sensibly
1c. Create kernel's own mapping (TTBR_EL1) 1c. Create kernel's own mapping (TTBR_EL1)
# What does the kernel MMU code support? ## What does the kernel MMU code support?
* mapping * mapping
* unmapping * unmapping
* switching per-process mappings (virtspaces) * switching per-process mappings (virtspaces)
@ -36,7 +38,8 @@ For more information please re-read.
* direct phys access for kernel (TTBR_EL1 mapping to physmem) * direct phys access for kernel (TTBR_EL1 mapping to physmem)
* initial kernel memory allocation: for mapping tables and capnodes, for initial thread TCB and stacks * initial kernel memory allocation: for mapping tables and capnodes, for initial thread TCB and stacks
# public api: ## public api
ARMMU invocations: ARMMU invocations:
on page directory cap on page directory cap
cache maintenance (clean/invalidate/unify) cache maintenance (clean/invalidate/unify)
@ -53,7 +56,8 @@ For more information please re-read.
on asid pool cap on asid pool cap
# Minimum Required Functionality (build from this) ## Minimum Required Functionality (build from this)
* resolve VA to PA - resolving lets kernel access mapped process memory. * resolve VA to PA - resolving lets kernel access mapped process memory.
(start from the process' virtspace root - Page Directory) (start from the process' virtspace root - Page Directory)
* flush page, pd, pt, virtspace - will be important for thread switching * flush page, pd, pt, virtspace - will be important for thread switching
@ -61,3 +65,32 @@ For more information please re-read.
* unmap entire mapped page table * unmap entire mapped page table
* map a phys frame to virt location * map a phys frame to virt location
* unmap a mapped frame * unmap a mapped frame
## Requirements
GIVEN
A PageGlobalDirectory of process
FIND
A kernel-physical address of where it contains a certain leaf node.
## sel4
> seL4 does not provide virtual memory management, beyond kernel primitives for manipulating hardware paging structures. User-level must provide services for creating intermediate paging structures, mapping and unmapping pages.
> Users are free to define their own address space layout with one restriction: the seL4 kernel claims the high part of the virtual memory range. On most 32-bit platforms, this is 0xe0000000 and above. This variable is set per platform, and can be found by finding the kernelBase variable in the seL4 source.
(from https://docs.sel4.systems/Tutorials/mapping.html)
> Note that to map a frame multiple times, one must make copies of the frame capability: each frame capability can only track one mapping.
## howto steps
initial mapping:
* for kernel space -
1. obtain memory map
2. build a list of regions available as RAM
3. find largest covering page sizes
4. allocate several memory pages and fill them with table info
(need page table creation functions here)
5. now kernel is able to address physical memory through it's (negative) kernel mapping.
6. prepare init thread VSpace
- this is more complicated wrt mapping