bhyve: Make boot ROM handling more consistent

- On amd64, deprecate lpc.bootrom and lpc.bootvars. Use top-level
config variables instead.
- Introduce a generic predicate which can be used to dete

bhyve: Make boot ROM handling more consistent

- On amd64, deprecate lpc.bootrom and lpc.bootvars. Use top-level
config variables instead.
- Introduce a generic predicate which can be used to determine whether
the guest has a boot ROM.

Reviewed by: corvink, jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D46282

show more ...

Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

bhyve: add varfile option to nvlist of lpc device

Use seperate nvlist entries for the romfile and the varfile.

While here, don't leak varfd in bootrom_loadrom().

Reviewed by: jhb, markj
Differe

bhyve: add varfile option to nvlist of lpc device

Use seperate nvlist entries for the romfile and the varfile.

While here, don't leak varfd in bootrom_loadrom().

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

show more ...

bhyve(8): Add bootrom allocation abstraction

To allow more general use of the bootrom region, separate initialization from
allocation, and allocation from loading a file.

The bootrom segment is the

bhyve(8): Add bootrom allocation abstraction

To allow more general use of the bootrom region, separate initialization from
allocation, and allocation from loading a file.

The bootrom segment is the high 16MB of the low 4GB region.

Each allocation in the segment creates a new mapping with specified protection.
By default, allocation begins at the low end of the range. However, the
BOOTROM_ALLOC_TOP flag is provided to locate a provided bootrom in the high
region it is expected to be in.

The existing ROM-file loading code is refactored to use the new interface.

Reviewed by: grehan (earlier version)
Differential Revision: https://reviews.freebsd.org/D24422

show more ...

Fix style(9) space vs tab.

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

Add SPDX tags to bhyve(8).

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

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 ...