Cosmetic changes to unp_internalize

Don't throw away the result of fget_unlocked.
Move fdp increment to for loop to make it consistent with similar code
elsewhere.

MFC after:	1 week
Fix builds on older FreeBSD versions and/or non-FreeBSD machines:
don't use _Static_assert unconditionally.
- Use Rs/Re mdoc macros.
- Remove duplicate and/or redundant content.
Prepare fget_unlocked for reading fd table only once.

Some capsicum functions accept fdp + fd and lookup fde based on that.
Add variants which accept fde.

Reviewed by:	pjd
MFC after:	1 week
Fix a bug where include file `networking/services.subr' was not being
properly clustered.

Change `fixedsize' to `fixedsize = true' to satisfy newer versions of dot(1)
generating error "Warning: <stdin>: syntax error in line 27 near ','".

Remove bounding cluster surrounding various include-groupings, allowing
groups of include files to float freely to the greatest consumer (reducing
the density of rendered diagrams).

While here, change the bgcolor of include clusters from white to X11 color
`thistle' (a light purple).

Also, add the word "Subroutines" after include cluster labels.

Do not terminate the digraph definition with a semi-colon [;] after the
ending brace to satisfy newer versions of dot(1) generating error "Warning:
<stdin>: syntax error in line 940 near ';'".

MFC after:	3 days
X-MFC-to:	stable/10, stable/9
Update so that clean target in sys/boot will delete the symlink
created for machine

Reviewed by:	emaste
Add .NOPATH to the machine target so that builds in sys/boot work and don't
error out building zfs loader.

Submitted by:	sjg@freebsd.org
Deprecate the use of XDEV and XDEV_ARCH and just use TARGET/TARGET_ARCH
for the xdev build target, which is awesome and totally works.

Reapply svn R268377 with correct name of libsupc++ here as this does
resolve one dependancy race when building the xdev target.

the xdev target builds for amd64, i386, mips, mips64 and armv6 with this commit,
must be built as root, must be built from /usr/src, must not have a /usr/obj and
places the xdev tools in /usr/$TARGET_ARCH-freebsd

the xdev target still leaves some assorted files strewn about your /usr/src when
this is done and needs to be investigated further.

Phabric:	https://phabric.freebsd.org/D385
Submitted by:	bsdimp
cxgbe(4):  Keep track of the clusters that have to be freed by the
custom free routine (rxb_free) in the driver.  Fail MOD_UNLOAD with
EBUSY if any such cluster has been handed up to the kernel but hasn't
been freed yet.  This prevents a panic later when the cluster finally
needs to be freed but rxb_free is gone from the kernel.

MFC after:	1 week
Fake out the deprecation of XDEV and XDEV_ARCH by
continuing to use the variables in the configuration
file, but switch XDEV= and XDEV_ARCH= to TARGET= and
TARGET_ARCH= appropriately.

Sponsored by:	The FreeBSD Foundation
Delete the entire cleandepend/cleanmachine target thing now that its been
cleared out in r269029

Reviewed by:	emaste@freebsd.org
When producing fmake(1), `make clean' should remove fmake.1 (a copy of
make.1). Introduced initially via SVN r250699 (sjg).

Reviewed by:	sjg, gjb
MFC after:	3 days
X-MFC-to:	stable/10
Clean symlinks created in sys/modules dirs when a make clean is invoked.

Phabric:	https://phabric.freebsd.org/D474
Reviewed by:	grehan sjg
Fix fault injection in bhyve.

The faulting instruction needs to be restarted when the exception handler
is done handling the fault. bhyve now does this correctly by setting
'vmexit[vcpu].inst_length' to zero so the %rip is not advanced.

A minor complication is that the fault injection APIs are used by instruction
emulation code that is shared by vmm.ko and bhyve. Thus the argument that
refers to 'struct vm *' in kernel or 'struct vmctx *' in userspace needs to
be loosely typed as a 'void *'.
Reduce the proliferation of VMEXIT_RESTART in task_switch.c.

This is in preparation for further simplification of the return values from
VM exit handlers in bhyve(8).
Add compat shims for XDEV and XDEV_ARCH so we don't break all the
users of them. Also, add a note to updating. We'll keep these shims at
least until the 12 branch.
- 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