Add a second temporary mapping to figure to make things clearer

This commit is contained in:
Philipp Oppermann
2019-03-13 12:02:59 +01:00
parent f34725de85
commit 23e70e0e9c
3 changed files with 9 additions and 2 deletions

View File

@@ -113,11 +113,16 @@ On x86_64, however, we can use [huge pages] with size 2MiB for the mapping, inst
For devices with very small amounts of physical memory, we could **map the page tables frames only temporarily** when we need to access them. To be able to create the temporary mappings we only need a single identity-mapped level 1 table: For devices with very small amounts of physical memory, we could **map the page tables frames only temporarily** when we need to access them. To be able to create the temporary mappings we only need a single identity-mapped level 1 table:
![A virtual and a physical address space with an identity mapped level 1 table, which maps its 0th entry to the level 2 table frame, thereby mapping that frame to page with address 0](temporarily-mapped-page-tables.png) ![A virtual and a physical address space with an identity mapped level 1 table, which maps its 0th entry to the level 2 table frame, thereby mapping that frame to page with address 0](temporarily-mapped-page-tables.svg)
The level 1 table in this graphic controls the first 2MiB of the virtual address space. This is because it is reachable by starting at the CR3 register and following the 0th entry in the level 4, level 3, and level 2 page tables. The entry with index `8` maps the virtual page at address `32KiB` to the physical frame at address `32KiB`, thereby identity mapping the level 1 table itself. The graphic shows this identity-mapping by the horizontal arrow at `32KiB`. The level 1 table in this graphic controls the first 2MiB of the virtual address space. This is because it is reachable by starting at the CR3 register and following the 0th entry in the level 4, level 3, and level 2 page tables. The entry with index `8` maps the virtual page at address `32KiB` to the physical frame at address `32KiB`, thereby identity mapping the level 1 table itself. The graphic shows this identity-mapping by the horizontal arrow at `32KiB`.
By writing to the identity-mapped level 1 table, our kernel can create up to 511 temporary mappings (512 minus the entry required for the identity mapping). In the above example, the kernel mapped the 0th entry of the level 1 table to the frame with address `24KiB`. This created a temporary mapping of the virtual page at `0KiB` to the physical frame of the level 2 page table, indicated by the dashed arrow. Now the kernel can access the level 2 page table by writing to the page starting at `0KiB`. By writing to the identity-mapped level 1 table, our kernel can create up to 511 temporary mappings (512 minus the entry required for the identity mapping). In the above example, the kernel created two temporary mappings:
- By mapping the 0th entry of the level 1 table to the frame with address `24KiB`, it created a temporary mapping of the virtual page at `0KiB` to the physical frame of the level 2 page table, indicated by the dashed arrow.
- By mapping the 9th entry of the level 1 table to the frame with address `4KiB`, it created a temporary mapping of the virtual page at `36KiB` to the physical frame of the level 4 page table, indicated by the dashed arrow.
Now the kernel can access the level 2 page table by writing to page `0KiB` and the level 4 page table by writing to page `33KiB`.
The process for accessing an arbitrary page table frame with temporary mappings would be: The process for accessing an arbitrary page table frame with temporary mappings would be:

Binary file not shown.

Before

Width:  |  Height:  |  Size: 44 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 36 KiB