The Design and Implementation of the Anykernel and Rump Kernels

94
Due to the design choice that a rump kernel does not use (nor require) a hardware
MMU, the virtual memory subsystem implementation is different from the regular
NetBSD VM. As already explained in Section 2.4, the most fundamental difference
is that there is no concept of page protection or a page fault inside the rump kernel.
The details of the rump kernel VM implementation along with their implications
are described in the following subsections. The VM is implemented in the source
module sys/rump/librump/rumpkern/vm.c. Additionally, routines used purely by
the file system faction are in sys/rump/librump/rumpvfs/vm_vfs.c.
Pages
When running on hardware, the pages described by the struct vmpage data structure
correspond with hardware pages 7 . Since the rump kernel does not interface
with memory management hardware, the size of the memory page is merely a programmatical
construct: the kernel hands out physical memory in multiples of the
page size. In a rump kernel this memory is allocated from the host and since there
is no memory protection or faults, the page size can in practice be any power of
two within a sensible size range. However, so far there has been no reason to use
anything different than the page size for the machine architecture the rump kernel
is running on.
TheVMtracksstatusofwhenapagewaslastused. Itdoesthistrackingeither
by asking the MMU on CPU architectures where that is supported, e.g. i386, or
by using memory protection and updating the information during page faults on
architectures where it is not, e.g. alpha.
This information is used by the page
daemon during memory shortages to decide which pages are best suited to be paged
7 This correspondence is not a strict rule. For example the NetBSD VAX port uses clusters of
512 byte contiguous hardware pages to create logical 4kB pages to minimize management overhead.