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.