Note it's late, and I may not be all that coherant, on a rather tricky area 
so accuracy is not guarenteed.

On Monday 04 June 2001  6:50 pm, John Fremlin wrote:
> 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")?

It's all to do with the L1 and L2 entries :)

L1 tables are the PDE's (page directory)
L2 tables are the PTE's (page table entries)

PDE's point at the PTE's, which then point at the real memory.  the PTE's 
have also to be in memory so are contained in page tables, and as we use a 
page for them they're called page table pages (ptp's)

the ptpt (page table page table) is the page table that contains the address 
of all the page tables.  When you add a new page table it's placed into the 
page directory (L1)  and also added to those in the ptpt so that we can 
easily track which addresses actually have a page table associated with them, 
but also to allow access to the physical page table (entries in the ptpt are 
of the physical addresses).

In total to map the full 4GB of VM you need 1 16k L1 table, and 1MB of L2 
page tables (256 4k page tables)  However we don't want to allocate all that 
so we do it sparsely, and use a ptpt to track which bits of VM space are 
actually used.

The ptpt's have to be accessible to the kernel, so it can manipulate the 
pte's, so they have a kernel VA. (see pmap_allocpagedir)  But they're also 
always at the same VA in the processes L1 table, so that if you're in the 
context of the process you can manipulate them.

I think in theory given the ptpt you can potentially rebuild the whole of the 
L1 table.

The whole thing is messy really, I still don't fully understand it, and need 
to write bits of all this up, so that it all makes sense to me.

Hmm in fact looking at the pmap_pte code, it might be pheasible to make use 
of the pmap->vptpt rather than mapping the ptpt into the current processes at 
the ALT_PAGE_TBLS_BASE.

The pmap is tricky thing to understand (and I admit I don't fully), I've  
found reading the UVM paper, and the design 4.4 BSD OS (the McKusick, Bostic, 
Karels and Quarterman book)  informative, and am only now starting to 
understand how it hangs together.  At some point I plan to draw this all up 
in some form that makes sense.  

> Robert Swindells <swindellsr@genrad.com> writes:
> > Most of the changes should be in the l1_sec_table. You can also
> > simplify things if you can live without real console support until
> > you jump into main().
>
> That is a myth IMHO. I get real console support with one call:
> consinit in initarm. No extra hassle involved at all. Don't know why
> people find it so difficult :-)

Depends if you've actually got the console etc in your VM space, if you've 
not then you've got no chance :)

> > >My version is about half the size, and it appears that the reason for
> > >that is my ommission to undertake certain necessary things.
> >
> > I would start from a clean copy and reapply your changes.
>
> As I said, rewrote from scratch. The {rpc,hpc,etc}_machdep.c are very
> very crufty. My edition is much shorter.

It's only run once, so it's not had that much work done on it, beyond it 
works ;)

> > >> I'm sure we can suggest some things to try.
> > >
> > >Currently my big problem is not understanding the kernel_ptpt
> > >business. It is a sort of array of the addresses to pagetables (?)
> > >that sometimes is treated as a pagetable (?).
> > >
> > >Then pmap_pte does not return the pte at all but the pagetable (or am
> > >I barking up the wrong tree?)
> >
> > You shouldn't need to change anything around that area.
>
> I'm trying to clean that area up :-)
>
> I gave up initially and transliterated most of the stuff relating to
> kernel_ptpt from rpc_machdep.c, and the boot process was getting quite
> far - past uvm_init in main(), IIRC. I figured that they blew up,
> because (if I interpret correctly) I didn't copy all of the
> kernel_ptpt stuff from rpc_machdep, but left out mapping the kernel in
> kernel_ptpt. I had a bunch of problems before that because there was
> too little virtual address space (somehow I had got hold of a
> vmparam.h with only 4Mb set for kva).

Well you should have an L1 pt of 16k, and then 1 page for the ptpt, which has 
to be self mapping.  The L1 should have entries for the kernel's L2 pt's and 
the ptpt at va PROCESS_PAGE_TBLS_BASE.  But yes the rpc should do most of 
this (albeit not very clear).

Chris