next up previous
Next: System Design Up: Nemesis Virtual Address and Previous: Goals

Subsections

System Architecture

 

This section presents the virtual memory system from an abstract point of view. A number of definitions are introduced, and a simple description of the overall system is given.

Some Definitions

  The following definitions are essential to the understanding of the Nemesis virtual memory system:

Virtual Address Space:
the set of valid virtual addresses. On a single machine in Nemesis, any process will `see' the same virtual address space, the only difference being the access rights that the process has on each part of the address space.

Physical Address Space:
the set of valid physical addresses. This includes any physically addressable location in a machine's memory, not just RAM.

Page:
the smallest protectable component of virtual address space. In a sense, it is the granularity of the virtual address space with regard to access control.

Frame:
the physical equivalent of a page. It is also likely to be the granularity at which areas of the physical address space are allocated. A frame typically contains the same number of bytes as a page.

Protection Domain:
a function from the set of pages in the virtual address space to the set of access rights . Each protection domain thus represents the protection environment in which domains execute.

Access Right:
zero or more of read, write, execute and meta, as applied to part of the virtual address space. These are described in Section 4.1.

Accessibility:
a function from the set of active protection domains to the set of access rights. Thus the accessibility of a page is the set of its access rights in every protection domain.

Stretch:
a contiguous adamantine region of the virtual address space with the same accessibility. This is similar to a region in Mach or Chorus, or even to a MS-DOS arena . It is not, however, to be confused with a Unix-style segment, which can shrink and grow at will -- a stretch corresponds to the same set of contiguous pages throughout its lifetime.

Stretches are also disjoint, i.e., they cannot overlap. One consequence is that stretches cannot be refined : if you have a stretch it doesn't make sense to talk to the VM system about a subset of the stretch.

A stretch must be associated with a stretch driver before it can be useful. A stretch by itself is merely an abstract object created by the stretch allocator; it has no meaning to the rest of the system and any attempts by a process to address memory within a stretch which has no stretch driver will result in an unresolvable page fault to the process. All it does have are base address, length and access rights.

Stretch Driver:
The entity that is associated with a stretch to provide physical resources, page fault handling, etc. The closest analog of a stretch driver in System VR4 is called a segment driver . In Mach, it is a memory object .

A stretch driver is something which provides physical resources to back the virtual addresses of the stretches it is responsible for. Stretch drivers acquire and manage their own physical RAM, etc., and are responsible for setting up virtual to physical mappings by invoking the translation system .

Frame Stack:
the set of frames granted to any individual domain and which it may use for the purpose of mapping.

Translation System:
a machine-specific component which provides for entering, removing, retrieving and updating both mapping and protection information for virtual addresses. It may be considered to be somewhat like a memory-management unit.

The above represent the fundamental abstractions of the Nemesis memory system; further concepts and terms will be introduced throughout the document when necessary.

General Architecture

Considering the basic definitions provided, it is useful to see how they can fit together in a coherent manner. This general architecture is shown in Figure 1. Although the illustration represents a very high-level description of the memory system, a few points are worth mentioning:


  
Figure 1: VM System Architecture
\begin{figure}
 \centerline{
\includegraphics {figures/basic_arch.eps}
}\end{figure}

One further aspect of note is that protection operations are shown as being carried out independently of the shared server responsible for address allocation. This is due to the protection model chosen which includes explicit rights for ``change permissions'' operations. The protection model, address allocation & translation, and fault handling are each described in more detail in Section 4.


next up previous
Next: System Design Up: Nemesis Virtual Address and Previous: Goals
Robin Fairbairns
2/17/1998