Re: pmap_extract(9) (was Re: xmd(4) (Re: XIP))

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Mon, Nov 01, 2010 at 03:55:01PM +0000, Eduardo Horvath wrote:
> On Mon, 1 Nov 2010, Masao Uebayashi wrote:
> 
> > I think pmap_extract(9) is a bad API.
> > 
> > After MD bootstrap code detects all physical memories, it gives
> > all the informations to UVM, including available KVA.  At this
> > point UVM knows all the available resources of virtual/physical
> > addresses.  UVM is responsible to manage all of these.
> 
> This is managed RAM.  What about I/O pages?

To access MMIO device pages, you need a physical address.  Physical
address space is single, linear resource on all platforms.  I wonder
why we can't manage it in MI way.

> 
> > Calling pmap_extract(9) means that some kernel code asks pmap(9)
> > to look up a physical address.  pmap(9) is only responsible to
> > handle CPU and MMU.  Using it as a lookup database is an abuse.
> > The only reasonable use of pmap_extract(9) is for debugging purpose.
> > I think that pmap_extract(9) should be changed like:
> > 
> >     bool pmap_mapped_p(struct pmap *, vaddr_t);
> > 
> > and allow it to be used for KASSERT()s.
> > 
> > The only right way to retrieve P->V translation is to lookup from
> > vm_map (== the fault handler).  If we honour this principle, VM
> > and I/O code will be much more consistent.
> 
> pmap(9) has always needed a database to keep track of V->P mappings(*) as 
> wll as P->V mappings so pmap_page_protect() can be implemented.  

pmap_extract() accesses page table (per-space).  pmap_page_protect()
accesses PV (per-page).  I think they're totally different...

> 
> Are you planning on moving the responsibility of tracking P->V mappings to 
> UVM?
> 
> * While you can claim that keeping track of P->V mappings is the primary 
> function of pmap(9) and a sideffect of page tables, that posits the 
> machine in quesion uses page tables.  In a machine with a software managed 
> TLB you could implement pmap(9) by walking the UVM structures on a page 
> fault and generating TLB entries from the vm_page structure.  This would 
> reduce the amount of duplicate informaion maintained by the VM subsystems.  
> However, UVM currently assumes pmap() remembers all forward and reverse 
> mappings.  If pmap() forgets them, bad things happen.
> 
> Eduardo

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635