> Date: Fri, 28 Mar 1997 13:21:22 -0800 (PST)
> From: "Eduardo E. Horvath" <eeh@one-o.com>

> On Fri, 28 Mar 1997, Jason Thorpe wrote:
> 
> > On Fri, 28 Mar 1997 10:04:47 -0800 (PST) 
> >  "Eduardo E. Horvath" <eeh@one-o.com> wrote:
> > 
> >  > Are there any facilities for allocating physical page frames witout
> >  > mapping them in?  Since I will only be accessing the pages though physical
> >  > addresses, I don't want to maintain the info about any virtual mappings
> >  > just so I can free them later on.  
> > 
> > I am currently working on a machine-independent interface for this.  I
> > assume you need this for some DMA application, perhaps a framegrabber?
> 
> No, actually it's for MMU page table mappings.  I'm trying to prevent
> potential TLB misses in the TLB miss handler.  While I could try to make
> the trap handlers re-entrant, that can cause other problems like infinite
> loopbacks, etc.

For the MMU tables problem, you might use the method Jeremy and I used
in the sun3x pmap design.  In that design all MMU tables are allocated
at initialization time in a way that allows simple conversion between
virtual and physical addresses. (The MMU tables are in a memory range
that is contiguously mapped.)  That allows the pmap code to modify any
MMU table through its virtual mapping, and to easly get the physical
addresses needed by the MMU.  This also means the total size of the
MMU translation memory is fixed, as is the "translation capacity."
One might think this a bad thing, but actually it prevents the need
for the pmap code to ever ask the higher levels of the VM code for
more memory (which avoids a lot of hair).  Instead, when we run out
of translation resources, we just throw away the oldest translation
and let the victim fault it back in later.

It's a simple fixed-size translation cache, managed LUR.
Of course, it's also new code, and may still have bugs...

Gordon