cvs commit: src/sys/amd64/amd64 amd64_mem.c src/sys/amd64/include specialreg.h src/sys/i386/i386 i686_mem.c src/sys/i386/include specialreg.h

[John Baldwin]

jhb         2008-03-12 22:09:19 UTC

  FreeBSD src repository

  Modified files:
    sys/amd64/amd64      amd64_mem.c 
    sys/amd64/include    specialreg.h 
    sys/i386/i386        i686_mem.c 
    sys/i386/include     specialreg.h 
  Log:
  The variable MTRR registers actually have variable-sized PhysBase and
  PhysMask fields based on the number of physical address bits supported
  by the current CPU.  The old code assumed 36 bits on i386 and 40 bits on
  amd64.  In truth, all Intel CPUs up until recently used 36 bits (a newer
  Intel CPU uses 38 bits) and all the Opteron CPUs used 40 bits.
  
  In at least one case (the new Intel CPU) having the size of the mask field
  wrong resulted in writing questionable values into the MTRR registers on
  the application processors (BSP as well if you modify the MTRRs via
  memcontrol or running X, etc.).  The result of the questionable physmask
  was that all of memory was apparently treated as uncached rather than
  write-back resulting in a very significant performance hit.
  
  Fix this by constructing a run-time mask for the PhysBase and PhysMask
  fields based on the number of physical address bits supported by the CPU.
  All 64-bit capable CPUs provide a count of PA bits supported via the
  0x80000008 extended CPUID feature, so use that if it is available.  If that
  feature is not available, then assume 36 PA bits.
  
  While I'm here, expand the (now-unused) macros for the PhysBase and
  PhysMask fields to the current largest possible value (52 PA bits).
  
  MFC after:      1 week
  PR:             i386/120516
  Reported by:    Nokia
  
  Revision  Changes    Path
  1.29      +24 -6     src/sys/amd64/amd64/amd64_mem.c
  1.45      +2 -2      src/sys/amd64/include/specialreg.h
  1.28      +24 -6     src/sys/i386/i386/i686_mem.c
  1.44      +2 -2      src/sys/i386/include/specialreg.h