#
e497fe86 |
|
02-Apr-2024 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Use vm_get_highmem_base() instead of hard-coding the value This reduces the coupling between libvmmapi (which creates the highmem segment) and bhyve, in preparation for the arm64 port. No functional change intended. Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40992
|
#
b0936440 |
|
16-Oct-2023 |
John Baldwin <jhb@FreeBSD.org> |
bhyve: Replace many fprintf(stderr, ...) calls with EPRINTLN EPRINTLN handles newlines appropriately when stdout/stderr have been reused as the backend for a serial port. For bhyverun.c itself, the rule this attempts to follow is to use regular fprintf/perror/warn/err prior to init_pci() (which is when serial ports are configured) and to switch to EPRINTLN afterwards. Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D42182
|
#
1d386b48 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\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
|
#
7d9ef309 |
|
24-Mar-2023 |
John Baldwin <jhb@FreeBSD.org> |
libvmmapi: Add a struct vcpu and use it in most APIs. This replaces the 'struct vm, int vcpuid' tuple passed to most API calls and is similar to the changes recently made in vmm(4) in the kernel. struct vcpu is an opaque type managed by libvmmapi. For now it stores a pointer to the VM context and an integer id. As an immediate effect this removes the divergence between the kernel and userland for the instruction emulation code introduced by the recent vmm(4) changes. Since this is a major change to the vmmapi API, bump VMMAPI_VERSION to 0x200 (2.0) and the shared library major version. While here (and since the major version is bumped), remove unused vcpu argument from vm_setup_pptdev_msi*(). Add new functions vm_suspend_all_cpus() and vm_resume_all_cpus() for use by the debug server. The underyling ioctl (which uses a vcpuid of -1) remains unchanged, but the userlevel API now uses separate functions for global CPU suspend/resume. Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D38124
|
#
98d920d9 |
|
08-Oct-2022 |
Mark Johnston <markj@FreeBSD.org> |
bhyve: Annotate unused function parameters MFC after: 1 week
|
#
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
|
#
866036f4 |
|
28-Nov-2021 |
Rebecca Cran <bcran@FreeBSD.org> |
bhyve: Support a _VARS.fd file for bootrom OVMF creates two separate .fd files, a _CODE.fd file containing the UEFI code, and a _VARS.fd file containing a template of an empty UEFI variable store. OVMF decides to write variables to the memory range just below the boot rom code if it detects a CFI flash device. So here we add just the barest facsimile of CFI command handling to bootrom.c that is needed to placate OVMF. Submitted by: D Scott Phillips <d.scott.phillips@intel.com> Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D19976 MFC After: 1 week
|
#
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
|
#
332eff95 |
|
08-Jan-2020 |
Vincenzo Maffione <vmaffione@FreeBSD.org> |
bhyve: add wrapper for debug printf statements Add printf() wrapper to use CR/CRLF terminators depending on whether stdio is mapped to a tty open in raw mode. Try to use the wrapper everywhere. For now we leave the custom DPRINTF/WPRINTF defined by device models, but we may remove them in the future. Reviewed by: grehan, jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D22657
|
#
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
|