bhyveload(8): document some SECURITY CONSIDERATIONS

The situation is improved now that we're running in a sandbox, but there
is still some host machine access that could be concerning depending on
t

bhyveload(8): document some SECURITY CONSIDERATIONS

The situation is improved now that we're running in a sandbox, but there
is still some host machine access that could be concerning depending on
the context. These concerns may be somewhat mitigated by the fact that
the host machine usually provides the loader binary, even when the guest
image is providing the loader scripts -- they only bring the lua
scripts, and they have to be able to execute arbitrary syscalls rather
than the interfaces provided by libsa(3).

Reviewed by: jhb, markj
Differential Revision: https://reviews.freebsd.org/D43299

show more ...

Remove $FreeBSD$: two-line nroff pattern

Remove /^\.\\"\n\.\\"\s*\$FreeBSD\$$\n/

bhyve: improve memory size documentation

A couple of minor memory size option related nits:

- use common name 'memsize' (instead of 'max-size' or just 'size')
- bhyve: update usage with memsize u

bhyve: improve memory size documentation

A couple of minor memory size option related nits:

- use common name 'memsize' (instead of 'max-size' or just 'size')
- bhyve: update usage with memsize unit suffix, drop legacy "MB"
unit
- bhyveload: update usage with memsize unit suffix
- bhyve(8): document default size
- bhyveload(8): use memsize formatting like it's done
in bhyve(8)

Reviewed by: wblock, grehan
Approved by: re (kib), wblock, grehan
Differential Revision: https://reviews.freebsd.org/D6952

show more ...

Merge ^/head r296007 through r296368.

MFH

Sponsored by: The FreeBSD Foundation

Add option -C to have the guest memory included in core files.
This aids in debugging OS loaders.

Merge from head

Sponsored by: Gandi.net

Merge from head

Sync up with head up to r289211.

Merge from head

Add option -l for specifying which OS loader to dlopen(3). By default
this is /boot/userboot.so. This option allows for the development and
use of other OS loaders.

Merge from head

Catch up with head, primarily for the 1.14.4.0 firmware.

Merge ^/head r284737 through r285152.

Fix issues detected by 'mandoc -Tlint bhyveload.8'

Pointed out by: wblock
Differential Revision: https://reviews.freebsd.org/D2762

Catch up with HEAD (r280229-r284686).

Merge ^/head r284188 through r284643.

Merge from head @274131

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 imprac

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

show more ...

IFC @r269962

Submitted by: Anish Gupta (akgupt3@gmail.com)

Merge head from 7/28

Sync to HEAD@r269943.

Sort command flags in usage output and the manpages.

use .Mt to mark up email addresses consistently (part2)

PR: 191174
Submitted by: Franco Fichtner <franco@lastsummer.de>

MFC @ r266724

An SVM update will follow this.