10.6.1 Memory Model

The x86 architecture supports a very complex virtual memory model involving both segmentation and paging; one of the goals of the OSKit's base environment support for the x86 is to smooth over some of this complexity, hiding the details that the OS doesn't want to deal with while still allowing the OS full freedom to use the processor's virtual memory mechanisms as it sees fit. This section describes the memory models supported and assumed by the base environment.

First, here is a summary of several important terms that are used heavily used in the following text; for full details on virtual, linear, and physical addresses on the x86 architecture, see the appropriate processor manuals.

• Physical addresses are the actual addresses seen on external I/O and memory busses, after segmentation and paging transformations have been applied.
• Linear addresses are absolute 32-bit addresses within the x86's paged address space, after segmentation has been applied but before page translation. The virtual addresses of simple ``paging-only'' architectures such as MIPS correspond to linear addresses on the x86.
• Virtual addresses are the logical addresses used by program code to access memory. To read an instruction or access a data item, the processor first converts the virtual address into a linear address using the segmentation mechanism, then translates the linear address to a physical address using paging.
• Kernel virtual addresses are the virtual addresses normally used by kernel code to access its own functions and data structures: in other words, addresses accessed through the kernel's segment descriptors.

The OSKit provides a standard mechanism, defined in base_vm.h (see Section 10.6.2), which is used throughout the base environment to maintain considerable independence from the memory model in effect. These facilities allow the base environment support code to avoid various assumptions about the relationships between kernel virtual addresses, linear addresses, and physical addresses. Client OS code can use these facilities as well if desired.

Of course, it is impractical for the base environment code to avoid assumptions about the memory model completely. In particular, the code assumes that, for ``relevant'' code and data (e.g., the functions implementing the base environment and the data structures they manipulate), kernel virtual addresses can be converted to and from linear or physical addresses by adding or subtracting an offset stored in a global variable. However, the code does not assume that these offsets are always the same (the client OS is allowed to change them dynamically), or that all available physical memory is mapped into the kernel's virtual address space, or that all linear memory is accessible through the kernel's data segment descriptors. Detailed information about the memory model assumptions made by particular parts of the base environment support are documented in the appropriate API sections.

If the OSKit's startup code is being used to start the OS, then the specific memory model in effect initially depends on the startup environment, described in later the appropriate sections. For example, for kernels booted from a MultiBoot boot loader, in the initial memory environment virtual addresses, linear addresses, and physical addresses are all exactly equal (the offsets are zero). On the other hand, for kernels loaded from DOS, linear addresses and physical addresses will still be equal but kernel virtual addresses will be at some offset depending on where in physical memory the kernel was loaded. Regardless of the initial memory setup, the client OS is free to change the memory model later as necessary.

XXX example memory maps

XXX explain how to change memory models at run-time