Thank you Jason for technical clarification.  I have been
puzzled by alpha TLB refill logic for long time.

Due to the consideration for post-R4000's virtual address
indexed cache, linear PTE array (whose contents == individual
PTE) in KSEG2 space must be solely manipulated thru the
range.  PTE is organized in a 10+10+12 tree indeed and
a projection to a single linear array is done just as how i386
pmap arranges.

L4/MIPS reports interesting researches on how 64bit address
space TLB refill logic is implemented.  They made researches
on several variants, and concluded it's effective to have software
managed a TLB entry pool (cache) for a fast refill and fall back
to longer path table-walk when the fast refill exception misses
the target TLB entry.  Use google to fetch papers.  I guess it's
true that their implementation is one of fastest MIPS TLB handler
on earth, however, it's designed for their own single address space
OS dynamic, not for rather traditional UNIX style processes.

Toru Nishimura

Jason R. Thorpe <thorpej@wasabisystems.com> enlighted me;

> And the TLB refill handler in the PALcode always uses the VPT.
> 
> The PALcode uses the ldq_p (Load Quadword Physical) insn to load the
> PTE through the linear VPT mapping... sort of.  It actually uses the
> ,v ("but, actually, do it with a virtual address") modifier.  Which
> means that it has exactly the same behavior as a normal ldq, but it
> has a different opcode (an opcode which is reserved for PAL mode).
> 
> So, in the TLB miss handler, the PALcode first checks to see if the
> faulting insn was an ldq_p,v, and if so, does a table-walk (using a
> normal ldq_p) to load a TLB entry for the VPT address that's being
> accessed, then returns from the fault, and the ldq_p,v succeeds, and
> a TLB entry is loaded for the original miss address.
> 
> --