Here's a somewhat long-winded explanation, just to make sure I cover
all the points.

There are two different reasons why we map pages:

1) because we expect to need the page Some Time Later.  This can
   happen when, e.g., `prefaulting' pages.  In this case the
   `access_type' is set to 0 and no special action is performed by the
   pmap.

2) because we need the page Right Now, possibly because we got a
   fault.  In this case, we know that the page is going to be accessed
   immediately after the fault handler returns (or, in some cases,
   immediately after pmap_enter() returns, as in /dev/mem handling).
   We don't want to take another fault just for R/M bit emulation;
   this is a complete waste of time.  So, the `access_type' serves to
   pass the information originally from the fault handler about the
   nature of the attempted access back from the VM system to the pmap,
   so that the pmap can preset the emulated R/M bits and avoid causing
   a second fault.

   On machines where the R/M bits are kept in hardware, this doesn't
   buy you much.  Given the typical pmap implementation structure of
   having `cached' copies of the R/M bits in the head of each p->v
   list, it could be used to preset those cached bits, giving a slight
   optimization on the next call to pmap_is_modified() or
   pmap_is_referenced().

   There is a secondary use for this on machines that do R/M bit
   emulation, as mentioned in my previous mail.  If pagemove() is
   implemented such that it flips pages around behind the VM system's
   back (as it does on the ARM), then the pages must be accessible all
   the time; the R/M bit emulation information (i.e. the attributes in
   the pmsegs) is not consistent in this case and must not be used.
   Mapping these pages with an access_type of READ|WRITE insures that
   R/M emulation never happens on those machines (assuming the pmap
   implementation has been changed appropriately), and thus avoids
   needing to switch to using pmap_remove() and pmap_enter() inside
   pagemove() (as some other ports have done, and which is slower).

I believe both SPARC platforms have hardware R/M bits, so there isn't
much need for any change there.