kernel - Align virtual_start, workaround possible HW VM bugs
authorMatthew Dillon <dillon@apollo.backplane.com>
Sat, 28 May 2016 22:56:13 +0000 (15:56 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Sat, 28 May 2016 22:56:13 +0000 (15:56 -0700)
commite172ba36a5ed520510b898ddc1929687d6e4e847
treea0322e48fc8d8e2915e597e1fe037e2a042052a1
parentf9fae8ba8947d0f6e60b51fa0cdd8bd0126b7f41
kernel - Align virtual_start, workaround possible HW VM bugs

* virtual_start is 2MB-aligned at the kernel load's end address.
  The page table mappings prior to this address are 2MB mappings.

  Additional SYSMAP()d space is reserved in early boot, such as
  the CMAP entries and the dmesg buffer.  The page table mappings
  in this area should all be 4K pages.

* Kernel virtual memory beyond the SYSMAP()d space is available for
  general allocation, but positioned such that only kldload modules will
  try to use it specifically.  Sascha (swildner) found that any initial
  kldload done after boot in vmware player 7.1.4 build-3848939 running
  on a i7-4770K based host would panic.

  A kernel core of this panic appears to show a corrupt pte in a location
  where the pte should have been read as 0.

* Doing an additional 2MB alignment of virtual_start after the SYSMAP()s
  appears to work around this corruption, which is this commit.  This
  means that the first general allocation in the kernel load portion of
  the kernel_map will be shifted to the next 2MB boundary past the SYSMAP()s.

* I can only speculate that the hardware is somehow getting confused, but
  I can't really fathon how it is getting confused because the SYSMAP
  reservations should all be using 4KB pages.
sys/platform/pc64/x86_64/pmap.c