- Copying and zeroing pages via temporary mappings involves updating the
  corresponding page tables followed by accesses to the pages in question.
  This sequence is subject to the situation exactly described in the "AMD64
  Architecture Programmer's Manual Volume 2: System Programming" rev. 3.23,
  "7.3.1 Special Coherency Considerations" [1, p. 171 f.]. Therefore, issuing
  the INVLPG right after modifying the PTE bits is crucial.
  For pmap_copy_page(), this has been broken in r124956 and later on carried
  over to pmap_copy_pages() derived from the former, while all other places
  in the i386 PMAP code use the correct order of instructions in this regard.
  Fixing the latter breakage solves the problem of data corruption seen with
  unmapped I/O enabled when running at least bare metal on AMD R-268D APUs.
  However, this might also fix similar corruption reported for virtualized
  environments.
- In pmap_copy_pages(), correctly set the cache bits on the source page being
  copied. This change is thought to be a NOP for the real world, though. [2]

1: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/24593_APM_v21.pdf

Submitted by:	kib [2]
Reviewed by:	alc, kib
MFC after:	3 days
Sponsored by:	Bally Wulff Games & Entertainment GmbH
Copying pages via temporary mappings in the !DMAP case of pmap_copy_pages()
involves updating the corresponding page tables followed by accesses to the
pages in question. This sequence is subject to the situation exactly described
in the "AMD64 Architecture Programmer's Manual Volume 2: System Programming"
rev. 3.23, "7.3.1 Special Coherency Considerations" [1, p. 171 f.]. Therefore,
issuing the INVLPG right after modifying the PTE bits is crucial (see also
r269050).
For the amd64 PMAP code, the order of instructions was already correct. The
above fact still is worth documenting, though.

1: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/24593_APM_v21.pdf

Reviewed by:	alc
Sponsored by:	Bally Wulff Games & Entertainment GmbH
Intel desktop Haswell CPUs may report benign corrected parity errors (see
HSD131 erratum in [1]) at a considerable rate. So filter these (default),
unless logging is enabled. Unfortunately, there really is no better way to
reasonably implement suppressing these errors than to just skipping them
in mca_log(). Given that they are reported for bank 0, they'd need to be
masked in MSR_MC0_CTL. However, P6 family processors require that register
to be set to either all 0s or all 1s, disabling way more than the one error
in question when using all 0s there. Alternatively, it could be masked for
the corresponding CMCI, but that still wouldn't keep the periodic scanner
from detecting these spurious errors. Apart from that, register contents of
MSR_MC0_CTL{,2} don't seem to be publicly documented, neither in the Intel
Architectures Developer's Manual nor in the Haswell datasheets.

Note that while HSD131 actually is only about C0-stepping as of revision
014 of the Intel desktop 4th generation processor family specification
update, these corrected errors also have been observed with D0-stepping
aka "Haswell Refresh".

1: http://www.intel.de/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-desktop-specification-update.pdf

Reviewed by:	jhb
MFC after:	3 days
Sponsored by:	Bally Wulff Games & Entertainment GmbH
Correct assertion.  The shadowing object cannot be tmpfs vm object,
and tmpfs object cannot shadow.  In other words, tmpfs vm object is
always at the bottom of the shadow chain.

Reported and tested by:	bdrewery
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week