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

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

On Fri, Nov 05, 2010 at 10:04:46AM -0700, Matt Thomas wrote:
> 
> On Nov 5, 2010, at 4:59 AM, Masao Uebayashi wrote:
> 
> > On Mon, Nov 01, 2010 at 03:52:11PM -0700, Matt Thomas wrote:
> >> 
> >> On Nov 1, 2010, at 8:55 AM, 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?
> >> 
> >> Indeed.  Also consider that pmap's are designed to have to have
> >> fast V->P translations, using that instead of UVM makes a lot of
> >> sense.
> > 
> > How does locking works?
> > 
> > My understanding is page tables (per-process) are protected by
> > struct vm_map (per-process).  (Or moving toward it.)
> 
> Unfortunately, that doesn't completely solve the problem since
> lookups will be done either by exception handlers or hardware 
> bypassing any locks.  These means that the page tables must be
> updated in a MP safe manner.

I spent some time to think of this.  I'm pretty sure I have a good
understanding of pmap vs. MP now.

I'll reply after doing a little more research.