MFC r335025:

Add SPDX tags to bhyve(8).

Discussed with: rgrimes, pfg and mav.
Obtained from: TrueOS
Sponsored by: iXsystems Inc.

MFC r334307, r335103-r335104

r334307:
Simplify macros EFPRINTF and EFFLUSH. [0]
Also stdarg(3) says that each invocation of va_start() must be paired
with a corresponding invocation of va_end() in the same function. [1]

Reported by: Coverity
CID: 1194318[0] and 1194332[1]
Discussed with: jhb
Sponsored by: iXsystems Inc.
Differential Revision: https://reviews.freebsd.org/D15548

r335103:
Fix style(9) space vs tab.

Reviewed by: jhb
Sponsored by: iXsystems Inc.
Differential Revision: https://reviews.freebsd.org/D15774

r335104:
Fix style(9) space vs tab.

Reviewed by: jhb
Sponsored by: iXsystems Inc.
Differential Revision: https://reviews.freebsd.org/D15768

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Restructure memory allocation in bhyve to support "devmem".

devmem is used to represent MMIO devices like the boot ROM or a VESA framebuffer
where doing a trap-and-emulate for every access is impractical. devmem is a
hybrid of system memory (sysmem) and emulated device models.

devmem is mapped in the guest address space via nested page tables similar
to sysmem. However the address range where devmem is mapped may be changed
by the guest at runtime (e.g. by reprogramming a PCI BAR). Also devmem is
usually mapped RO or RW as compared to RWX mappings for sysmem.

Each devmem segment is named (e.g. "bootrom") and this name is used to
create a device node for the devmem segment (e.g. /dev/vmm/testvm.bootrom).
The device node supports mmap(2) and this decouples the host mapping of
devmem from its mapping in the guest address space (which can change).

Reviewed by: tychon
Discussed with: grehan
Differential Revision: https://reviews.freebsd.org/D2762
MFC after: 4 weeks