> 
> Could someone bear with another question from me, and elucidate the
> reasoning behind and layout of the PROCESS_PAGE_TBLS_BASE area (or has
> its origin been lost in the midst of time, marked "here be dragons")?
> 

OK, let me see what I can remember (I'm doing this at least partly for my own benefit).

Each process has, as part of its layout a complete mapping of its own page tables.  This allows the kernel to update the map for a process which faults for some reason without having to go look for the page tables for that process.

It also has a complete mapping of the kernel page tables, so that the kernel can run from the process tables without having to do a tlb switch (very expensive with a VAC, still quite expensive witout one).

This means that the kernel will run from the process tables of any process (including a special process table which is just the kernel -- used, I think, when there is no runnable process).

The page tables for the kernel are shared, so an update to one process is correctly mapped through to all the others.

All page tables are currently mapped NCNB, which is a major drag on performance -- expect this to be fixed soon(ish :-).

The page tables live immediately below KVM and enough space has to be left to map the entire 4GB address space using 4k pages and 4 bytes per page table entry (this is PAGE_TABLE_SPACE) and hence they live at PAGE_TABLE_SPACE_START; PROCESS_PAGE_TBLS_BASE is just an alias for this address.  This address space will then contain level2 mappings for any page so mapped: the relevent page table entry for any page with a second-level mapping will be a simple offset into this address space based on the page size and the size of each mapping.  With 4k pages, the total size of this space is 4MB.

In addition to this, each process has, of course, one L1 page table, which is 16K of contiguous memory on a 16K physical boundary (because each 4k L2 page is entered 4 times).  The virtual address of this is held in the pmap structure as pm_pdir.

Finally, there is ALT_PAGE_TBLS_BASE, the intention of which is to create temporary mappings of a page table from another process into a current process.  This is used, for example, when copying data from one process to another.  The code that implements this in the current ARM pmap is woeful, and we end up remapping it (and hence flushing tlbs) every time we look for a pte in a pmap that isn't the current one :-(.

As to some of the history behind this, some is definitely lost in the mists of time.  The original arm pmap code was derived from the old i386 pmap code; and after he had ported it, Mark commented that it probably wasn't the best place to start from.  Since then, of course, the i386 pmap has been completely rewritten, and the current version would have formed a much better starting place.

R.