[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pmap_extract(9) (was Re: xmd(4) (Re: XIP))
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
* 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.
Main Index |
Thread Index |