| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'll implement my own allocator later. Currently using linked-list
allocator [1] to manage the kernel heap (as in kmalloc, not vmalloc). It
manages the ID-mapped region (from VA 0xffff_8000_0000_0000). This
allocator is initialized to use the _largest_ physical memory block. If
the kernel image (text and data) live in this zone then skip the
occupied part.
Key difference between kmalloc and vmalloc:
- kmalloc pretty much manages the physical memory: the allocated address
are within the id-mapped region (see above) therefore the allocated
memory must also be contigous in physical memory. Such memory MUST NOT
page fault. This is prone to fragmentation, so do not use kmalloc to
allocate big objects (e.g. bigger than one 4k page).
- vmalloc manages kernel heap memory and the mapping is managed by
paging. Such memory could trigger pagefault in kernel mode.
Note that the kmalloc conflicts with the previous used stack based PMA
as they operates on the same VM zone.
References: [1] https://github.com/rust-osdev/linked-list-allocator
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
| |
Also renamed a few symbols to avoid confusion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we use the first pml4 entry (+one pdp table) to map phy 0~512G
to virt 0~512G for init code. This doesn't change.
For the kernel to work in higher half memory, we also need to create
mapping for it. We take the 256th entry of pml4 entry (hence one
additional pdp table).
Entry 0~63 are mapped to to the physical memory
(with offset 0xffff_8000_0000_0000)
Entry 64~127 are not used
Entry 128~191 are mapped to the kernel image (text and code)
(with offset 0xffff_8020_0000_0000)
details in docs/mem_layout.txt
|
| |
|
|
| |
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| |
|
|
|
|
|
| |
use 8MiB reserved array to manage up to 4GiB of physical memory
(4K Pages only)
Signed-off-by: Tianhao Wang <shrik3@mailbox.org>
|
| | |
|
| |
|
