Map all physical memory into the higher half instead of using recursive mapping #23

Merged
apio merged 6 commits from map-physical-world into main 2023-02-27 11:59:51 +00:00
Owner

Recursive mapping seemed like a neat idea, but it has its shortcomings. Namely, to edit an address space you must switch to it. Which is NOT CONVENIENT AT ALL when you're trying to manage two address spaces at once, like in fork().

This patch makes it so that x86_64's MMU maps the entire physical address space at 0xffff8000'00000000 (beginning of the higher half on x86_64) and then uses that mapping to perform further virtual memory operations.

This still has a few problems. Notably, we are not using huge pages for this mapping, which would be a lot more efficient.
Right now, used memory is 8.1 MiB at boot for a 256MiB system.
But after improving it, this system will be much better than recursive mapping.

Recursive mapping seemed like a neat idea, but it has its shortcomings. Namely, to edit an address space you must switch to it. Which is NOT CONVENIENT AT ALL when you're trying to manage two address spaces at once, like in fork(). This patch makes it so that x86_64's MMU maps the entire physical address space at 0xffff8000'00000000 (beginning of the higher half on x86_64) and then uses that mapping to perform further virtual memory operations. This still has a few problems. Notably, we are not using huge pages for this mapping, which would be a lot more efficient. Right now, used memory is 8.1 MiB at boot for a 256MiB system. But after improving it, this system will be much better than recursive mapping.
apio added 1 commit 2023-02-27 11:27:39 +00:00
x86_64/MMU: Map all physical memory into the higher half instead of using recursive mapping
All checks were successful
continuous-integration/drone/pr Build is passing
995d1bc36e
This still has a few problems. Notably, we are not using huge pages for this mapping, which would be a lot more efficient.
Right now, used memory is 8.1 MiB at boot for a 256MiB system.
But after improving it, this system will be much better than recursive mapping.
fork() will be MUCH easier to implement, for example.
apio added 1 commit 2023-02-27 11:30:59 +00:00
x86_64/MMU: Copy from the mapped kernel directory instead of the physical version
All checks were successful
continuous-integration/drone/pr Build is passing
837d483e0b
apio added the
enhancement
label 2023-02-27 11:31:39 +00:00
apio self-assigned this 2023-02-27 11:31:44 +00:00
apio removed their assignment 2023-02-27 11:31:52 +00:00
apio self-assigned this 2023-02-27 11:33:00 +00:00
apio added 3 commits 2023-02-27 11:51:37 +00:00
apio added 1 commit 2023-02-27 11:55:22 +00:00
x86_64/MMU: Do not allocate level 1 page tables for huge page entries
All checks were successful
continuous-integration/drone/pr Build is passing
continuous-integration/drone/push Build is passing
3ec54fafde
This would leak memory, since we would never end up using them.
Author
Owner

There we go, we're now using 188KiB out of 256MiB on boot.

There we go, we're now using 188KiB out of 256MiB on boot.
apio changed title from WIP: Map all physical memory into the higher half instead of using recursive mapping to Map all physical memory into the higher half instead of using recursive mapping 2023-02-27 11:58:42 +00:00
apio merged commit 3ec54fafde into main 2023-02-27 11:59:51 +00:00
Sign in to join this conversation.
No reviewers
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: apio/Luna#23
No description provided.