Memory Management is the most important part of XenevaOS, as it is a process of controlling and coordinating installed available memory, assigining portions called blocks to various running programs and deallocate it when they are done. Xeneva manages memory through two subsystem, Physical Memory and Virtual Memory, Both are very important part of Xeneva’s Memory Management subsystem and many memory management layers heavily depends on Physical Memory Manager and Virtual Memory Manager. Three components of Memory Managers are:
Xeneva uses ‘Paging’ mechanism to manage available installed memory, as ‘Paging’ is a efficient memory management scheme that eliminates the need for contiguous allocation of physical memory, thus solving the problem of fitting varying-sized memory chunks onto the backing store. By default Xeneva uses 4KiB (4096 bytes) pages. The initialization process of Physical Memory Manager involves two phases: The XNLDR phase and The Kernel phase.
The XNLDR phase prepares a basic Physical Memory Manager in order to load the kernel and its runtime resources and the Kernel phase prepares a full time Physical Memory Manager. The data structure used to manage Physical Memory in XNLDR is dereferenced pointer and the data structure used in Kernel is Bitmap allocation.
The Virtual Memory manager in XenevaOS involves two phases same like Physical Memory Manager, The XNLDR phase & the Kernel Phase. XNLDR creates a temporary paging structure and loads the Kernel into higher half address. The Kernel creates a new paging structure with additional steps like Linear Mapping the entire Physical Memory and Clearing the Lower Half section.
Linear Mapping the entrire Physical Memory involves the mapping of Physical address linearly from 0xFFFF800000000000. For example if physical allocation at address 0x11B5000 is done than it would look like 0xFFFF8000011B5000. This is done via special functions P2V and V2P. The P2V function converts a physical address to its linear virtual address and V2P converts a linear virtual address to its actual physical address. Linear mapping is important for process management. The lower half of Virtual Memory is reserved for process and the Higher Half is fixed for Kernel and its resources and is shared among all processes.
For a process an entire new Virtual Memory is created. Where Kernel code is shared between all processes through the higher half section. Benifits of creating an entire new Address space for each process is it isolates the process from accessing a memory area from another process. Linear mapping helps in isolating the address spaces of different processes.
Clearing the lower half section: Clearing the lower half section is only possible if the Kernel is using Linear addresses for allocating Physical memory for any reason. For example if a driver would allocate a physical memory through AuPmmngrAlloc function, the function must uses Linear address to allocate a physical block. When Virtual Memory Manager initializes itself it automatically store the information whether the memory manager has linearly mapped all the physical memory or not. This helps the Physical Memory Manager to decide whether to allocate Physical Block from linear address or non linear address. If anywhere inside the kernel, a physical block is allocated from non-linear space, clearing the lower half section would cause immediate crash.
The AuVmmngrBootFree function clear out the lower half section and store the new paging structure into CR3 register.
MMIO Memory Area: The Virtual Address starting from 0xFFFFFF1000000000. This region is reserved for Hardware to map its device registers into the virtual address space. This region is also marked as non-cacheable region. The ‘AuMapMMIO’ function is used to map device memories into MMIO Region.
The External Functions of Virtual Memory Manager: External functions in Virtual Memory Manager are marked with ‘Ex’ suffix with their function name. There are only two external function currently available, AuMapPageEx and AuGetPhysicalAddressEx.
AuMapPageEx: In Xeneva, mapping a physical address to a virtual address from one address space to another address space is possible through this function. The destination address space need not to be switched from current address space. Switching address space involves writing the address space to control register. Xeneva doesn’t follow fork-exec model of Unix, whenever a process is created from current process, an entire new new process slot is created rather than copying the current process and replacing it with new executable. Whenever new process is created from running process via service call, AuMapPageEx is used for mapping physical memory to virtual memory in newly created process’s address space without switching to that address space even temporarily.
AuGetPhysicalAddressEx: Similar to AuMapPageEx getting a physical address of a virtual address from one address space to another is also possible, through this function. This function is used in AuProcessClean which is used by init process, init process is responsible for cleaning all dead processes.
Between multiple process a shared memory plays a very important role in passing data with low latency. ProcessA may create a shared memory segment with a specific key, and pass that key to ProcessB through arguments or inter-process communication mechanism. ProcessB would create a new shared memory segment with the provided key and access the shared memory segment. Only the common thing that both the processes have is the physical address. ProcessA create a completely fresh shared memory segment with a physical block backend to it, ProcessB create a shared memory segment with the key provided by ProcessA. The difference is in ProcessB creating the shared memory segment, the Shared Memory Manager looks for the key that ProcessB used for creating a new segment, if it is already present in Shared Memory Manager, the Shared Memory Manager simply maps the physical addresses from the already created segment to the newly created segment. Through this ProcessA can pass information to ProcessB with low latency.
Shared Memory is very useful for low latency information passing between two or more then two processes. The Display Server in XenevaOS and all the Graphical Application heavily depends on the Shared Memory Manager. Shared Memory Manager is also used between Audio Server and its client processes.
Shared memory segment is created with the function AuCreateSHM and shareable memory is obtained a from the newly created segment through the AuSHMObtainMem function.
AuCreateSHM: Creates a new shared memory segment’s parameters:
AuSHMObtainMem: Obtains a memory from newly created shared memory segment. Its parameters are: