20 A-1 Basic Concepts
A-1.1 Cells
Cells are an architectural concept that is useful for describing the partitioning of system resources and commu-
nication channels between OKL4 programs. It is important to note that there are no kernel objects called cells
and no kernel APIs that deal with cells.
On a simple level, the term cell may be used to refer to a single application which is strongly isolated from
other applications in the system. Alternatively on a more complex level, the term cell may be used to refer
complex component based system or an entire virtual machine.
A cell may contain multiple address spaces, though a cell does not require more than one address space. In cells
containing multiple address spaces, at least one address space must be associated with a kenel memory pool,
global identifier partitions and physical memory regions. This address space is referred to as the cell manager.
Other address spaces in the cell cannot directly create kernel objects and must proxy through the cell manager.
It should be noted that the OKL4 API allows the user to specify more complex constructs, such as dynamically
creating address spaces that share the same resources as the cell manager. Though is legally permissable under
the OKL4 API, it falls outside the cell architectural model. The cell manager may freely distribute capabilities
that it posesses to any capability lists that it creates, and thus to any applications it controls.
A cell has a fixed allocation of the underlying hardware, that is, as well as having the use of a specific kernel
memory pool and ranges of physical memory, cells may manage specific devices and be granted access to
specific interrupts. Thus a cell may be considered to be a virtual machine.
A powerful property of the cell architecture is that a cell can only communicate with other cells, if it is enabled
by Elfweaver at build time. A cell cannot increase its access rights at run-time.
For further information regarding the Elfweaver tool, please refer to the Elfweaver Reference Manual.
A-1.2 Memory Sections
A memory section or memsection is a contiguous range of virtual memory, which can then be backed in physical
memory. Memsections provided by the OKL4 library have designed to be small and flexible. Thus, they are a
useful mechanism for determining mapping policy. It should be noted that the memsections themselves do not
directly track memory mappings.
A memsection object stores the range of virtual addresses covered by the memsection, together with the per-
missions and attributes to use when mapping the memsection and callbacks that determine the way in which
it is mapped. The permissions define the access rights to the memory (read, write, execte or any combination
thereof). It is the responsibility of the user to ensure that the permissions are supported by the underlying
hardware. The attributes determine how the memory is cached, for example, write-back, write-through or un-
chached. As with attributes, the user is expected to use the correct architecture-dependent values. The virtual
address range maybe allocated from a pool or directly set. In either case the user must allocate the range prior
to initializing the memsection.
The callbacks are function pointers to lookup, map and destroy functions to be used by that memsection. The
map callback is equivalent to lookup if a mapping already exists for that virtual address. For example, this may
occur if a memsection was shared with another address space and paged in on-demand. If no mapping is found,
map will allocate some physical memory and return a physmem item containing all information regarding the
physical allocation. In addition, the map and lookup callbacks return the attributes, permissions, page size and
p roperly-aligned virtual address to use when mapping. The lookup callback simply translates a virtual address
into a physmem item, using additional state about the existing physical memory mappings that is external to
the memsection structure, but it does not modify any state. The destroy callback cleans up any additional state
associated with the memsection that is external to the memsection structure. Note that no mappings are ever
performed by the callbacks or any other memsection functions. They only provide the information necessary
to perform a mapping, and leave it up to the user of the memsection to make the system calls. In most cases
a higher l evel of the virtual memory system will have this responsibilty. For example, zones and protection
domains will perform mappings as memsections are attached and detached.
The library also provides an implementation of static memsections, which are contiguous in physical memory
and entirely pre-mapped. They are equivalent to normal memsections in Iguana and are also a simple example
Open Kernel Labs DRAFT OK 40292:2008(2)
我的内容管理
展开
