/*
* Copyright (c) 1996
* The President and Fellows of Harvard College. All rights reserved.
* Copyright (c) 1992, 1993
* The Regents of the University of California. All rights reserved.
*
* This software was developed by the Computer Systems Engineering group
* at Lawrence Berkeley Laboratory under DARPA contract BG 91-66 and
* contributed to Berkeley.
*
* All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by Aaron Brown and
* Harvard University.
* This product includes software developed by the University of
* California, Lawrence Berkeley Laboratory.
*
* @InsertRedistribution@
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by Aaron Brown and
* Harvard University.
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)pmap.h 8.1 (Berkeley) 6/11/93
*/
/*
* Pmap structure.
*
* The pmap structure really comes in two variants, one---a single
* instance---for kernel virtual memory and the other---up to nproc
* instances---for user virtual memory. Unfortunately, we have to mash
* both into the same structure. Fortunately, they are almost the same.
*
* The kernel begins at 0xf8000000 and runs to 0xffffffff (although
* some of this is not actually used). Kernel space, including DVMA
* space (for now?), is mapped identically into all user contexts.
* There is no point in duplicating this mapping in each user process
* so they do not appear in the user structures.
*
* User space begins at 0x00000000 and runs through 0x1fffffff,
* then has a `hole', then resumes at 0xe0000000 and runs until it
* hits the kernel space at 0xf8000000. This can be mapped
* contiguously by ignoring the top two bits and pretending the
* space goes from 0 to 37ffffff. Typically the lower range is
* used for text+data and the upper for stack, but the code here
* makes no such distinction.
*
* Since each virtual segment covers 256 kbytes, the user space
* requires 3584 segments, while the kernel (including DVMA) requires
* only 512 segments.
*
*
** FOR THE SUN4/SUN4C
*
* The segment map entry for virtual segment vseg is offset in
* pmap->pm_rsegmap by 0 if pmap is not the kernel pmap, or by
* NUSEG if it is. We keep a pointer called pmap->pm_segmap
* pre-offset by this value. pmap->pm_segmap thus contains the
* values to be loaded into the user portion of the hardware segment
* map so as to reach the proper PMEGs within the MMU. The kernel
* mappings are `set early' and are always valid in every context
* (every change is always propagated immediately).
*
* The PMEGs within the MMU are loaded `on demand'; when a PMEG is
* taken away from context `c', the pmap for context c has its
* corresponding pm_segmap[vseg] entry marked invalid (the MMU segment
* map entry is also made invalid at the same time). Thus
* pm_segmap[vseg] is the `invalid pmeg' number (127 or 511) whenever
* the corresponding PTEs are not actually in the MMU. On the other
* hand, pm_pte[vseg] is NULL only if no pages in that virtual segment
* are in core; otherwise it points to a copy of the 32 or 64 PTEs that
* must be loaded in the MMU in order to reach those pages.
* pm_npte[vseg] counts the number of valid pages in each vseg.
*
* XXX performance: faster to count valid bits?
*
* The kernel pmap cannot malloc() PTEs since malloc() will sometimes
* allocate a new virtual segment. Since kernel mappings are never
* `stolen' out of the MMU, we just keep all its PTEs there, and have
* no software copies. Its mmu entries are nonetheless kept on lists
* so that the code that fiddles with mmu lists has something to fiddle.
*
** FOR THE SUN4M/SUN4D
*
* On this architecture, the virtual-to-physical translation (page) tables
* are *not* stored within the MMU as they are in the earlier Sun architect-
* ures; instead, they are maintained entirely within physical memory (there
* is a TLB cache to prevent the high performance hit from keeping all page
* tables in core). Thus there is no need to dynamically allocate PMEGs or
* SMEGs; only contexts must be shared.
*
* We maintain two parallel sets of tables: one is the actual MMU-edible
* hierarchy of page tables in allocated kernel memory; these tables refer
* to each other by physical address pointers in SRMMU format (thus they
* are not very useful to the kernel's management routines). The other set
* of tables is similar to those used for the Sun4/100's 3-level MMU; it
* is a hierarchy of regmap and segmap structures which contain kernel virtual
* pointers to each other. These must (unfortunately) be kept in sync.
*
*/
#define NKREG ((int)((-(unsigned)KERNBASE) / NBPRG)) /* i.e., 8 */
#define NUREG (256 - NKREG) /* i.e., 248 */
TAILQ_HEAD(mmuhd,mmuentry);
/*
* data appearing in both user and kernel pmaps
*
* note: if we want the same binaries to work on the 4/4c and 4m, we have to
* include the fields for both to make sure that the struct kproc
* is the same size.
*/
struct pmap {
union ctxinfo *pm_ctx; /* current context, if any */
int pm_ctxnum; /* current context's number */
u_int pm_cpuset; /* CPU's this pmap has context on */
int pm_refcount; /* just what it says */
struct mmuhd pm_reglist; /* MMU regions on this pmap (4/4c) */
struct mmuhd pm_seglist; /* MMU segments on this pmap (4/4c) */
struct regmap *pm_regmap;
int **pm_reg_ptps; /* SRMMU-edible region tables for 4m */
int *pm_reg_ptps_pa;/* _Physical_ address of pm_reg_ptps */
int pm_gap_start; /* Starting with this vreg there's */
int pm_gap_end; /* no valid mapping until here */
struct regmap {
struct segmap *rg_segmap; /* point to NSGPRG PMEGs */
int *rg_seg_ptps; /* SRMMU-edible segment tables (NULL
* indicates invalid region (4m) */
smeg_t rg_smeg; /* the MMU region number (4c) */
u_char rg_nsegmap; /* number of valid PMEGS */
};
struct segmap {
uint64_t sg_wiremap; /* per-page wire bits (4m) */
int *sg_pte; /* points to NPTESG PTEs */
pmeg_t sg_pmeg; /* the MMU segment number (4c) */
u_char sg_npte; /* number of valid PTEs in sg_pte
* (not used for 4m/4d kernel_map) */
int8_t sg_nwired; /* number of wired pages */
};
#ifdef _KERNEL
#define PMAP_NULL ((pmap_t)0)
/* Mostly private data exported for a few key consumers. */
struct memarr;
extern struct memarr *pmemarr;
extern int npmemarr;
extern vaddr_t prom_vstart;
extern vaddr_t prom_vend;
/*
* Bounds on managed physical addresses. Used by (MD) users
* of uvm_pglistalloc() to provide search hints.
*/
extern paddr_t vm_first_phys, vm_last_phys;
extern psize_t vm_num_phys;
/*
* Since PTEs also contain type bits, we have to have some way
* to tell pmap_enter `this is an IO page' or `this is not to
* be cached'. Since physical addresses are always aligned, we
* can do this with the low order bits.
*
* The ordering below is important: PMAP_PGTYPE << PG_TNC must give
* exactly the PG_NC and PG_TYPE bits.
*/
#define PMAP_OBIO 1 /* tells pmap_enter to use PG_OBIO */
#define PMAP_VME16 2 /* etc */
#define PMAP_VME32 3 /* etc */
#define PMAP_NC 4 /* tells pmap_enter to set PG_NC */
#define PMAP_TNC_4 7 /* mask to get PG_TYPE & PG_NC */
/*
* On a SRMMU machine, the iospace is encoded in bits [3-6] of the
* physical address passed to pmap_enter().
*/
#define PMAP_TYPE_SRMMU 0x78 /* mask to get 4m page type */
#define PMAP_PTESHFT_SRMMU 25 /* right shift to put type in pte */
#define PMAP_SHFT_SRMMU 3 /* left shift to extract iospace */
#define PMAP_TNC_SRMMU 127 /* mask to get PG_TYPE & PG_NC */
/*#define PMAP_IOC 0x00800000 -* IO cacheable, NOT shifted */
/* pmap_{zero,copy}_page() may be assisted by specialized hardware */
#define pmap_zero_page (*cpuinfo.zero_page)
#define pmap_copy_page (*cpuinfo.copy_page)
/*
* For each managed physical page, there is a list of all currently
* valid virtual mappings of that page. Since there is usually one
* (or zero) mapping per page, the table begins with an initial entry,
* rather than a pointer; this head entry is empty iff its pv_pmap
* field is NULL.
*/
struct vm_page_md {
struct pvlist {
struct pvlist *pv_next; /* next pvlist, if any */
struct pmap *pv_pmap; /* pmap of this va */
vaddr_t pv_va; /* virtual address */
int pv_flags; /* flags (below) */
} pvlisthead;
};
#define VM_MDPAGE_PVHEAD(pg) (&(pg)->mdpage.pvlisthead)
