|PMAP(9)||Kernel Developer's Manual||PMAP(9)|
pmap — machine
dependent interface to the MMU
describes how the physical mapping is done between the user-processes and
kernel virtual addresses and the physical addresses of the main memory,
providing machine-dependent translation and access tables that are used
directly or indirectly by the memory-management hardware. The
pmap layer can be viewed as a big array of mapping
entries that are indexed by virtual address to produce a physical address
and flags. These flags describe the page's protection, whether the page has
been referenced or modified and other characteristics.
pmap interface is consistent across
all platforms and hides the way page mappings are stored.
Modified/referenced information is only tracked for pages managed
by uvm(9) (pages for which a
vm_page structure exists). Only managed mappings of those pages have
modified/referenced tracking. The use of unmanaged mappings should be
limited to code which may execute in interrupt context (such as
malloc(9)) or to enter
mappings for physical addresses which are not managed by
uvm(9). This allows
pmap modules to avoid blocking interrupts when
manipulating data structures or holding locks. Unmanaged mappings may only
be entered into the kernel's virtual address space. The modified/referenced
bits must be tracked on a per-page basis, as they are not attributes of a
mapping, but attributes of a page. Therefore, even after all mappings for a
given page have been removed, the modified/referenced bits for that page
must be preserved. The only time the modified/referenced bits may be cleared
is when uvm(9) explicitly calls
functions. These functions must also change any internal state necessary to
detect the page being modified or referenced again after the
modified/referenced state is cleared.
Mappings entered by
are managed, mappings entered by
pmap, vaddr_t va,
va, paddr_t pa,
pmap, vaddr_t sva,
function creates a managed mapping for physical page
pa at the specified virtual address
va in the target physical map
pmap with protection specified by
The flags argument contains protection bits (the same bits used in the prot argument) indicating the type of access that caused the mapping to be created. This information may be used to seed modified/referenced information for the page being mapped, possibly avoiding redundant faults on platforms that track modified/referenced information in software. Other information provided by flags:
pmap_enter() is allowed to fail. If this flag is not set, and the
pmap_enter() call is unable to create the mapping, perhaps due to insufficient resources, the
pmapmodule must panic.
The access type provided in the flags argument will never exceed the protection specified by prot.
function is called by the fault routine to establish a mapping for the page
being faulted in. If
pmap_enter() is called to enter
a mapping at a virtual address for which a mapping already exists, the
previous mapping must be invalidated.
is sometimes called to change the protection for a pre-existing mapping, or
to change the “wired” attribute for a pre-existing
function creates an unmanaged mapping of physical address
pa at the specified virtual address
va with the protection specified by
function removes the range of virtual addresses sva to
eva from pmap, assuming proper
pmap_remove() is called during an unmap
operation to remove low-level machine dependent mappings.
function removes an unmanaged mapping at virtual address
va of size size.
A call to
must be made after
pmap_kremove() to notify the
pmap layer that the mappings need to be made
pmap, vaddr_t sva,
vm_page *pg, vm_prot_t prot);
function clears the wired attribute for a map/virtual-address pair. The
mapping must already exist in pmap.
function sets the physical protection on range sva to
eva, in pmap.
function is called during a copy-on-write operation to write protect
copy-on-write memory, and when paging out a page to remove all mappings of a
function sets the permission for all mapping to page
function is called before a pageout operation to ensure that all pmap
references to a page are removed.
functions read/set the modify bits on the specified physical page
pmap_clear_reference() functions read/set the
reference bits on the specified physical page pg.
pmap_is_modified() functions are called by the
pagedaemon when looking for pages to free. The
pmap_clear_modify() functions are called by the
pagedaemon to help identification of pages that are no longer in demand.
vm_page *src, struct
function copies the content of the physical page src
to physical page dst.
function fills page with zeroes.
function creates an instance of the pmap structure.
function increments the reference count on pmap.
function decrements the reference count on physical map
pmap and retires it from service if the count drops to
zero, assuming it contains no valid mappings.
Wired memory allocation before the virtual
memory system is bootstrapped is accomplished by the
function. After that point, the kernel memory allocation routines should be
function can preallocate kernel page tables to a specified virtual
function notifies the
pmap module to force
processing of all delayed actions for all pmaps.
function informs the
pmap module that the given
pmap is not expected to be used for some time, giving the
pmap module a chance to prioritize. The initial
bounds of the kernel virtual address space are returned by
function copies the range specified by src_addr and
src_len from src_pmap to the
range described by dst_addr and
dst_len in dst_map.
pmap_copy() is called during a
fork(2) operation to give the
child process an initial set of low-level mappings.
module is based on Mach 3.0. The introduction of
uvm(9) left the
pmap interface unchanged for the most part.
Ifdefs must be documented.
pmap_update() should be mandatory.
|December 31, 2008||OpenBSD-5.1|