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