[ Moving this to tech-kern, BCC'ing the list it was previously on.  --thorpej ]

On Fri, 29 Jan 1999 09:38:47 -0500 
 Chuck Cranor <chuck@research.att.com> wrote:

 >    i looked at this on the i386 a while back but i haven't had
 > time to figure out how to fix it.   the problem on the i386 is that
 > pmap_kenter() adds kernel mappings without bumping up the kernel
 > pmap's pm_stats.resident_count  [it can't bump it as-is because
 > it doesn't have a lock on the kernel pmap's simplelock.]

Why doesn't it just acquire that lock, then?  Is it defined in the
pmap_kenter() API that the kernel pmap will not be locked?

...what if a given pmap implementation MUST lock the kernel pmap to
enter a mapping?

This actually brings up another problem w/ pmap_kenter() that I've
been meaning to bring up.

The big deal with pmap_kenter() is that it's faster than the normal
pmap_enter() path, because it can make some assumptions... it also
has the specified feature of not doing PV tracking, which is required
for uvm_loan() to work (prevents certain mappings from being e.g.
pmap_page_protect()'d, etc.)

Unfortunately, the lack of PV-tracking has two problems:

	(1) For hardware mod/ref, if you must traverse the PV list
	    to get this information, you may lose mod/ref info!

	    For software mod/ref emulation (e.g. Alpha), you have the
	    problem of not being able to set those mappings to Fault on
	    Read/Fault on Write, and thus you also lose mod/ref info!

	(2) On VAC systems (like the HP 320 and HP 350 and on the MIPS R4000),
	    it's necessary to cache-inhibit all mappings if a multiple-mapping
	    causes a VAC alias (not likely with PMAP_PREFER(), but can
	    still happen).  Without these PV entries, we can't cache
	    inhibit all mappings, and thus we have a cache coherency problem!

What I'm thinking about doing on the Alpha and hp300 pmaps is instead
use a bit to say "entered w/ kenter" in the PV entry, so that the
desired operations (e.g. pmap_page_protect()) are skipped on those
mappings, but the info can be tracked for the other needs.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>