cvs commit: src/sys/amd64/amd64 pmap.c

[Alan Cox]

alc         2008-03-23 20:38:01 UTC

  FreeBSD src repository

  Modified files:
    sys/amd64/amd64      pmap.c 
  Log:
  To date, we have assumed that the TLB will only set the PG_M bit in a
  PTE if that PTE has the PG_RW bit set.  However, this assumption does
  not hold on recent processors from Intel.  For example, consider a PTE
  that has the PG_RW bit set but the PG_M bit clear.  Suppose this PTE
  is cached in the TLB and later the PG_RW bit is cleared in the PTE,
  but the corresponding TLB entry is not (yet) invalidated.
  Historically, upon a write access using this (stale) TLB entry, the
  TLB would observe that the PG_RW bit had been cleared and initiate a
  page fault, aborting the setting of the PG_M bit in the PTE.  Now,
  however, P4- and Core2-family processors will set the PG_M bit before
  observing that the PG_RW bit is clear and initiating a page fault.  In
  other words, the write does not occur but the PG_M bit is still set.
  
  The real impact of this difference is not that great.  Specifically,
  we should no longer assert that any PTE with the PG_M bit set must
  also have the PG_RW bit set, and we should ignore the state of the
  PG_M bit unless the PG_RW bit is set.  However, these changes enable
  me to remove a work-around from pmap_promote_pde(), the superpage
  promotion procedure.
  
  (Note: The AMD processors that we have tested, including the latest,
  the Phenom, still exhibit the historical behavior.)
  
  Acknowledgments: After I observed the problem, Stephan (ups) was
  instrumental in characterizing the exact behavior of Intel's recent
  TLBs.
  
  Tested by: Peter Holm
  
  Revision  Changes    Path
  1.608     +17 -38    src/sys/amd64/amd64/pmap.c