Next: System Design
Up: Nemesis Virtual Address and
Previous: Goals
Subsections
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.
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.
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
 |
- There is a clear separation of address allocation
and address translation .
This in accordance with the Nemesis philosophy of distinguishing
between control- and data-path operations: allocation by its very
nature requires a form of central arbitration to prevent conflict
between multiple applications, while translation
may be safely carried out without the involvement of any central
authority.
- A stretch is directly involved with virtual addresses and
protection; a stretch driver is directly involved with physical
resources and stretches.
This emphasises the definitions given earlier: a
stretch represents merely a range of virtual addresses with a
certain accessibility. It does not own -- nor is it guaranteed -- any
physical resources. It is only via its association with a stretch
driver that it becomes possible to talk meaningfully about its
``contents''.
- The kernel (viz. NTSC) is not involved save for fault
notification.
This fits with the general structure of Nemesis -- the NTSC provides
only a small set of system calls and the scheduler. It does not
play a large part in the virtual memory architecture presented
here.
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: System Design
Up: Nemesis Virtual Address and
Previous: Goals
Robin Fairbairns
2/17/1998