On Sun, Mar 24, 2002 at 02:07:39PM +0900, Takao Shinohara wrote:
> Chuck Silvers <chuq@chuq.com> writes:
> > the problem with using pmap_enter() instead of pmap_kenter_pa()
> > for pages that are loaned to the kernel is that we need to make
> > sure that the loan mappings for these pages are not removed by
> > pmap_page_protect(VM_PROT_NONE).  if the page loaned to the kernel
> > is owned by a vnode object and the file is truncated such that the
> > page is now past the end of the file, we need to be able to leave
> > the loan mappings alone while removing all other mappings.
> > the way to do this is to use pmap_kenter_pa() for loan mappings
> > and pmap_enter() for non-loan mappings, then pmap_page_protect()
> > removes exactly the mappings we want.
> 
> Should pmap_kenter_pa() call pmap_enter_pv()?

as things stand today, no, it should not.

there are several constraints here.  pmap_kenter_pa() cannot fail,
so it really shouldn't be allocating memory (such as a pv entry).
also, it must be safe for interrupt handlers to call pmap_kenter_pa()
even though callers of other pmap interfaces that manipulate pv entries
are not required to block interrupts.  yes, all the other interfaces
could block interrupts internally but that's not very desirable either.

one change that might improve things would be to add a new PMAP_LOAN
flag for pmap_enter(), which would indicate that the mapping is a
loan-to-kernel mapping.  platforms with VACs could create pv entries
for these mappings (so that alias-detection would be triggered)
but mark them so that pmap_page_protect() would skip them.
there are probably additional subtleties here.  however, this would be
a substantial change so I wouldn't want to pursue it right now.
the current design works well enough for the impending release.

-Chuck