From WhitixDoc

Source reference

arch/i386/mm/virt.c

virt.c handles the low-level mapping of virtual memory onto physical memory

Memory management series

Introduction Physical page allocator Mapping virtual memory Memory mapping and files Slab allocator

Virtual memory in Whitix is mapped into the processes address space by architecture-specific functions. The virtual memory functions, such as VirtMemMapPage, VirtMapPhysPage and VirtAllocateTemp, typically request a page from the physical page allocator, and map it to a certain page table and directory in the address space of the current process.

Contents 1 Initialisation 2 Process and address spaces 3 Page directory and page table access 4 Mapping and unmapping one page 5 Mapping over a memory range

Initialisation

As part of the architecture-specific kernel setup, VirtInit (line 230) is called. This function calls VirtMemManagerInit to set up the kernel page directory and page tables, and then sets up the slab allocator.

VirtMemManagerInit does the main work of setting up the initial memory space for the kernel. It maps the first 8MB of physical memory to the first 8MB of virtual memory (while mapping the kernel code pages read-only), by creating two page directories. It then maps the page directories and tables at the top of virtual memory (see below), and enables paging, by setting the page directory register (cr3) and enabling the paging bit in cr0.

Process and address spaces

Each process, on creation, is allocated its own memory manager (and address space) using VirtMemManagerInit. Kernel memory (0xC0000000 onwards) is shared between all processes; VirtMemPage handles mapping each page directory into each process' address space. When one of the processes' threads run, the task switching code calls VirtSetCurrent, which changes address space.

Page directory and page table access

In VirtMemManagerInit, the page directory and tables are mapped to the top of the virtual address space. (0xFFC00000, by placing the page directory address in the last entry in the page directory itself). This allows the virtual memory mapping functions to alter the page directories and tables directory, without having to map page tables into another part of memory.

The processor accesses virtual memory pages through the normal method; page directory is the high 10 bits of the address, the page table is the next 10, and the offset is the lowest 12 bits.

Mapping and unmapping one page

The basic function to map a virtual address to a physical one is VirtMemMapPage. This first checks if a page directory exists for the virtual address that will be mapped. If not, it is created and zeroed, and if the new page directory is in kernel space, it is mapped into the address space of all other processes. Once the page directory entry exists, the page table entry can be updated (with the physical page address and relevant permissions) and the cache flushed (with invlpg).

To unmap a page in VirtUnmapPhysPage, the page table entry is set to zero, and the cache flushed.

Mapping over a memory range

When the slab allocator needs to map virtual pages to physical memory, it has to map multiple pages over a range of addresses (the slab allocator is given an address range from 0xC0000000 to 0xD0000000). It uses VirtMapPhysRange, which effectively checks there are numPages free page table entries following each other, and then maps them using VirtMemMapPage.

Developer manual > Kernel overview > Mapping virtual memory

This short article needs expansion or improvement. Why not help?