d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

amd64 pmap: explain ptepindex.

Browse Source 
Reviewed by:	markj
Discussed with:	alc
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D25187
This commit is contained in:
kib 2020-06-27 19:29:07 +00:00
parent eb1c123d53
commit 0730d174fe
1 changed files with 23 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
sys/amd64/amd64/pmap.c
View File

@ -3807,6 +3807,29 @@ pmap_pinit(pmap_t pmap)
* one or two pages may be held during the wait, only to be released
* afterwards. This conservative approach is easily argued to avoid
* race conditions.
*
* The ptepindexes, i.e. page indices, of the page table pages encountered
* while translating virtual address va are defined as follows:
* - for the page table page (last level),
* ptepindex = pmap_pde_pindex(va) = va >> PDRSHIFT,
* in other words, it is just the index of the PDE that maps the page
* table page.
* - for the page directory page,
* ptepindex = NUPDE (number of userland PD entries) +
* (pmap_pde_index(va) >> NPDEPGSHIFT)
* i.e. index of PDPE is put after the last index of PDE,
* - for the page directory pointer page,
* ptepindex = NUPDE + NUPDPE + (pmap_pde_index(va) >> (NPDEPGSHIFT +
* NPML4EPGSHIFT),
* i.e. index of pml4e is put after the last index of PDPE.
*
* Define an order on the paging entries, where all entries of the
* same height are put together, then heights are put from deepest to
* root. Then ptexpindex is the sequential number of the
* corresponding paging entry in this order.
*
* The root page at PML4 does not participate in this indexing scheme, since
* it is statically allocated by pmap_pinit() and not by _pmap_allocpte().
*/
static vm_page_t
_pmap_allocpte(pmap_t pmap, vm_pindex_t ptepindex, struct rwlock **lockp)