[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, 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
> * 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.
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Main Index |
Thread Index |