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

asleepymoon · 2023-02-27T11:27:39Z

asleepymoon commented

2023-02-27 11:27:39 +00:00

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.

asleepymoon 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

continuous-integration/drone/pr Build is passing

Details

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.

asleepymoon 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

continuous-integration/drone/pr Build is passing

Details

837d483e0b

asleepymoon added the

enhancement

label 2023-02-27 11:31:39 +00:00

asleepymoon self-assigned this 2023-02-27 11:31:44 +00:00

asleepymoon removed their assignment 2023-02-27 11:31:52 +00:00

asleepymoon self-assigned this 2023-02-27 11:33:00 +00:00

asleepymoon added 3 commits 2023-02-27 11:51:37 +00:00

x86_64: Allow mapping huge pages, but don't do it yet 426f6e4da8

x86_64/MMU: Map the physical address space using huge pages 8df441064f

MemoryManager: Reuse the existing mapping of physical memory that MMU has

continuous-integration/drone/pr Build is passing

Details

752dfdbf1c

asleepymoon 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

continuous-integration/drone/pr Build is passing

Details

continuous-integration/drone/push Build is passing

Details

3ec54fafde

This would leak memory, since we would never end up using them.

asleepymoon commented

2023-02-27 11:56:05 +00:00

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

asleepymoon 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

asleepymoon merged commit 3ec54fafde into main

2023-02-27 11:59:51 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: asleepymoon/Luna#23