Import svn-1.8.0 final
Import subversion-1.8.1 into vendor staging area.
Import svn-1.8.4, which includes fixes for both security and merge
handling.
Import subversion-1.8.5
Vendor import svn-1.8.8
Vendor import svn-1.8.9
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