#
b3e76948 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: two-line .h pattern Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
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
|
#
87f6367f |
|
03-Mar-2022 |
Corvin Köhne <CorvinK@beckhoff.com> |
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
|
#
bb30b08e |
|
14-Apr-2020 |
Conrad Meyer <cem@FreeBSD.org> |
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
|
#
f7224b70 |
|
13-Jun-2018 |
Marcelo Araujo <araujo@FreeBSD.org> |
Fix style(9) space vs tab. Reviewed by: jhb MFC after: 3 weeks. Sponsored by: iXsystems Inc. Differential Revision: https://reviews.freebsd.org/D15768
|
#
ce80faa4 |
|
12-Jun-2018 |
Marcelo Araujo <araujo@FreeBSD.org> |
Add SPDX tags to bhyve(8). Discussed with: rgrimes, pfg and mav. Obtained from: TrueOS MFC after: 4 weeks. Sponsored by: iXsystems Inc.
|
#
9b1aa8d6 |
|
18-Jun-2015 |
Neel Natu <neel@FreeBSD.org> |
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
|