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

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

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?

> 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.  

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