system/freebsd-src
system/freebsd-src
1
0
Fork 0
mirror of https://github.com/freebsd/freebsd-src synced 2024-10-15 21:05:08 +00:00
Code Issues Packages Projects Releases Wiki Activity
freebsd-src/usr.sbin/bhyve/Makefile

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

135 lines
2.3 KiB
Makefile
Raw Normal View History

Import of bhyve hypervisor and utilities, part 1. vmm.ko - kernel module for VT-x, VT-d and hypervisor control bhyve - user-space sequencer and i/o emulation vmmctl - dump of hypervisor register state libvmm - front-end to vmm.ko chardev interface bhyve was designed and implemented by Neel Natu. Thanks to the following folk from NetApp who helped to make this available: Joe CaraDonna Peter Snyder Jeff Heller Sandeep Mann Steve Miller Brian Pawlowski
2011-05-13 04:54:01 +00:00
#
#
Add VNC Authentication support based on RFC6143 section 7.2.2. Submitted by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de> Reworked by: myself Reviewed by: grehan, rgrimes and jilles MFC after: 1 week. Relnotes: Yes. Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D10818
2017-06-02 02:35:16 +00:00
.include <src.opts.mk>
Import of bhyve hypervisor and utilities, part 1. vmm.ko - kernel module for VT-x, VT-d and hypervisor control bhyve - user-space sequencer and i/o emulation vmmctl - dump of hypervisor register state libvmm - front-end to vmm.ko chardev interface bhyve was designed and implemented by Neel Natu. Thanks to the following folk from NetApp who helped to make this available: Joe CaraDonna Peter Snyder Jeff Heller Sandeep Mann Steve Miller Brian Pawlowski
2011-05-13 04:54:01 +00:00
PROG= bhyve
Make FreeBSD-bhyve an indivual package
2015-03-05 07:30:48 +00:00
PACKAGE= bhyve
Import of bhyve hypervisor and utilities, part 1. vmm.ko - kernel module for VT-x, VT-d and hypervisor control bhyve - user-space sequencer and i/o emulation vmmctl - dump of hypervisor register state libvmm - front-end to vmm.ko chardev interface bhyve was designed and implemented by Neel Natu. Thanks to the following folk from NetApp who helped to make this available: Joe CaraDonna Peter Snyder Jeff Heller Sandeep Mann Steve Miller Brian Pawlowski
2011-05-13 04:54:01 +00:00
Refactor configuration management in bhyve. Replace the existing ad-hoc configuration via various global variables with a small database of key-value pairs. The database supports heirarchical keys using a MIB-like syntax to name the path to a given key. Values are always stored as strings. The API used to manage configuation values does include wrappers to handling boolean values. Other values use non-string types require parsing by consumers. The configuration values are stored in a tree using nvlists. Leaf nodes hold string values. Configuration values are permitted to reference other configuration values using '%(name)'. This permits constructing template configurations. All existing command line arguments now set configuration values. For devices, the "-s" option parses its option argument to generate a list of key-value pairs for the given device. A new '-o' command line option permits setting an individual configuration variable. The key name is always given as a full path of dot-separated components. A new '-k' command line option parses a simple configuration file. This configuration file holds a flat list of 'key=value' lines where the 'key' is the full path of a configuration variable. Lines starting with a '#' are comments. In general, bhyve starts by parsing command line options in sequence and applying those settings to configuration values. Once this is complete, bhyve then begins initializing its state based on the configuration values. This means that subsequent configuration options or files may override or supplement previously given settings. A special 'config.dump' configuration value can be set to true to help debug configuration issues. When this value is set, bhyve will print out the configuration variables as a flat list of 'key=value' lines. Most command line argments map to a single configuration variable, e.g. '-w' sets the 'x86.strictmsr' value to false. A few command line arguments have less obvious effects: - Multiple '-p' options append their values (as a comma-seperated list) to "vcpu.N.cpuset" values (where N is a decimal vcpu number). - For '-s' options, a pci.<bus>.<slot>.<function> node is created. The first argument to '-s' (the device type) is used as the value of a "device" variable. Additional comma-separated arguments are then parsed into 'key=value' pairs and used to set additional variables under the device node. A PCI device emulation driver can provide its own hook to override the parsing of the additonal '-s' arguments after the device type. After the configuration phase as completed, the init_pci hook then walks the "pci.<bus>.<slot>.<func>" nodes. It uses the "device" value to find the device model to use. The device model's init routine is passed a reference to its nvlist node in the configuration tree which it can query for specific variables. The result is that a lot of the string parsing is removed from the device models and centralized. In addition, adding a new variable just requires teaching the model to look for the new variable. - For '-l' options, a similar model is used where the string is parsed into values that are later read during initialization. One key note here is that the serial ports use the commonly used lowercase names from existing documentation and examples (e.g. "lpc.com1") instead of the uppercase names previously used internally in bhyve. Reviewed by: grehan MFC after: 3 months Differential Revision: https://reviews.freebsd.org/D26035
2019-06-26 20:30:41 +00:00
MAN= bhyve.8 bhyve_config.5
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
Don't use SYSDIR to avoid conflicts with existing usage. Also, use SRCTOP to locate the top of the source tree instead of a relative path. PR: 208856
2016-04-20 17:05:32 +00:00
BHYVE_SYSDIR?=${SRCTOP}
Allow the location of the kernel source tree to be overridden. This makes it easier for the bhyve executable to be built out of the tree.
2016-04-10 05:58:19 +00:00
bhyve: Start moving machine-dependent code into subdirectories In preparation for an arm64 port, make an easy change which puts some machine-dependent code in its own directory. Going forward, code which is only used on one platform should live in a MD directory. We should strive to layer modules in such a way as to avoid polluting shared code with lots of ifdefs. For some existing files this will take some effort. task_switch.c and fwctl.c are an easy place to start: the former is very x86-specific, and the latter provides an I/O port interface which can't be used on anything other than x86. (fwcfg as implemented has the same problem, but QEMU also supports a MMIO fwcfg interface.) So I propose that we start by simply making those files conditional. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40501
2023-10-04 16:20:37 +00:00
.PATH: ${.CURDIR}/${MACHINE_CPUARCH} \
${SRCTOP}/sys/libkern \
${SRCTOP}/sys/cam/ctl
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
SRCS= \
bhyve: Sort SRCS No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D40553
2023-06-15 16:21:54 +00:00
acpi.c \
bhyve: add helper struct for acpi device handling To simplify the handling of different acpi devices like qemu fwcfg or a tpm, add a helper struct. It will handle the reporting of acpi resources. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D38327
2021-10-07 13:54:46 +00:00
acpi_device.c \
Replay r349335 by scottl accidentally reverted by r349352 Add the PCI HDAudio device model from the 2016 GSoC. Detailed information can be found at https://wiki.freebsd.org/SummerOfCode2016/HDAudioEmulationForBhyve This commit has evolved from the original work to include Capsicum integration. As part of that, it only opens the host audio devices once and leaves them open, instead of opening and closing them on each guest access. Thanks to Peter Grehan and Marcelo Araujo for their help in bringing the work forward and providing some of the final techncial push. Submitted by: Alex Teaca <iateaca@freebsd.org> Differential Revision: D7840, D12419
2019-06-25 06:14:05 +00:00
audio.c \
bhyve: add basic basl implementation Basl is the bhyve ASL compiler. At the moment, it's just a small wrapper to call iasl, the Intel ASL compiler. As bhyve will gain support for qemu's ACPI table loader in the future, it has to create ACPI tables on it's own. Therefore, it makes sense to create a new file which keeps the code for basl. This first implementation of basl supports creating an ACPI table by appending raw bytes to it. It's also capable of loading all tables into guest memory. Reviewed by: jhb, markj (older version) Approved by: manu (mentor) MFC after: 2 weeks Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D36984
2022-11-04 11:24:49 +00:00
basl.c \
Import bhyve_graphics into CURRENT. Thanks to all who tested this on the branch. Original commit message: Initial bhyve native graphics support. This adds emulations for a raw framebuffer device, PS2 keyboard/mouse, XHCI USB controller and a USB tablet. A simple VNC server is provided for keyboard/mouse input, and graphics output. A VGA emulation is included, but is currently disconnected until an additional bhyve change to block out VGA memory is committed. Credits: - raw framebuffer, VNC server, XHCI controller, USB bus/device emulation and UEFI f/w support by Leon Dang - VGA, console/g, initial VNC server by tychon@ - PS2 keyboard/mouse jointly done by tychon@ and Leon Dang - hypervisor framebuffer mem support by neel@ Tested by: Michael Dexter, in a number of revisions of this code. With the appropriate UEFI image, FreeBSD, Windows and Linux guests can installed and run in graphics mode using the UEFI/GOP framebuffer. Approved by: re (gjb)
2016-07-04 03:19:06 +00:00
bhyvegc.c \
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
bhyverun.c \
bhyve: Move vcpu initialization into a MD source file - Make handling of x86 config options, like x86.x2apic, conditional to amd64. - Move fbsdrun_set_capabilities() and spinup_vcpu() to a new file, bhyverun_machdep.c. The moved code is all highly x86 specific. I'm not sure how best to handle the namespace. I'm using "bhyve_" for MD functions called from MI code. We also have "fbsdrun_" for some MI routines that are typically called from MD code. The file name is prefixed by "bhyverun_". Reviewed by: corvink MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40987
2023-10-04 16:27:07 +00:00
bhyverun_machdep.c \
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
block_if.c \
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
2015-06-18 06:00:17 +00:00
bootrom.c \
Refactor configuration management in bhyve. Replace the existing ad-hoc configuration via various global variables with a small database of key-value pairs. The database supports heirarchical keys using a MIB-like syntax to name the path to a given key. Values are always stored as strings. The API used to manage configuation values does include wrappers to handling boolean values. Other values use non-string types require parsing by consumers. The configuration values are stored in a tree using nvlists. Leaf nodes hold string values. Configuration values are permitted to reference other configuration values using '%(name)'. This permits constructing template configurations. All existing command line arguments now set configuration values. For devices, the "-s" option parses its option argument to generate a list of key-value pairs for the given device. A new '-o' command line option permits setting an individual configuration variable. The key name is always given as a full path of dot-separated components. A new '-k' command line option parses a simple configuration file. This configuration file holds a flat list of 'key=value' lines where the 'key' is the full path of a configuration variable. Lines starting with a '#' are comments. In general, bhyve starts by parsing command line options in sequence and applying those settings to configuration values. Once this is complete, bhyve then begins initializing its state based on the configuration values. This means that subsequent configuration options or files may override or supplement previously given settings. A special 'config.dump' configuration value can be set to true to help debug configuration issues. When this value is set, bhyve will print out the configuration variables as a flat list of 'key=value' lines. Most command line argments map to a single configuration variable, e.g. '-w' sets the 'x86.strictmsr' value to false. A few command line arguments have less obvious effects: - Multiple '-p' options append their values (as a comma-seperated list) to "vcpu.N.cpuset" values (where N is a decimal vcpu number). - For '-s' options, a pci.<bus>.<slot>.<function> node is created. The first argument to '-s' (the device type) is used as the value of a "device" variable. Additional comma-separated arguments are then parsed into 'key=value' pairs and used to set additional variables under the device node. A PCI device emulation driver can provide its own hook to override the parsing of the additonal '-s' arguments after the device type. After the configuration phase as completed, the init_pci hook then walks the "pci.<bus>.<slot>.<func>" nodes. It uses the "device" value to find the device model to use. The device model's init routine is passed a reference to its nvlist node in the configuration tree which it can query for specific variables. The result is that a lot of the string parsing is removed from the device models and centralized. In addition, adding a new variable just requires teaching the model to look for the new variable. - For '-l' options, a similar model is used where the string is parsed into values that are later read during initialization. One key note here is that the serial ports use the commonly used lowercase names from existing documentation and examples (e.g. "lpc.com1") instead of the uppercase names previously used internally in bhyve. Reviewed by: grehan MFC after: 3 months Differential Revision: https://reviews.freebsd.org/D26035
2019-06-26 20:30:41 +00:00
config.c \
Import bhyve_graphics into CURRENT. Thanks to all who tested this on the branch. Original commit message: Initial bhyve native graphics support. This adds emulations for a raw framebuffer device, PS2 keyboard/mouse, XHCI USB controller and a USB tablet. A simple VNC server is provided for keyboard/mouse input, and graphics output. A VGA emulation is included, but is currently disconnected until an additional bhyve change to block out VGA memory is committed. Credits: - raw framebuffer, VNC server, XHCI controller, USB bus/device emulation and UEFI f/w support by Leon Dang - VGA, console/g, initial VNC server by tychon@ - PS2 keyboard/mouse jointly done by tychon@ and Leon Dang - hypervisor framebuffer mem support by neel@ Tested by: Michael Dexter, in a number of revisions of this code. With the appropriate UEFI image, FreeBSD, Windows and Linux guests can installed and run in graphics mode using the UEFI/GOP framebuffer. Approved by: re (gjb)
2016-07-04 03:19:06 +00:00
console.c \
ext2fs: extract crc16 into sys/crc16.h deduplicate this as it might be needed for other drivers (e.g. Apple SPI-HID) Sponsored by: https://www.patreon.com/valpackett Reviewed by: chuck, imp MFC after: 1 month Differential revision: https://reviews.freebsd.org/D32879
2023-04-24 09:41:52 +00:00
crc16.c \
ctl: Support NVMe requests in debug trace functions Reviewed by: imp Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D44719
2024-05-02 23:31:34 +00:00
ctl_nvme_all.c \
- Add bhyve virtio-scsi storage backend support. Example of configuration: ctl.conf: portal-group pg0 { discovery-auth-group no-authentication listen 0.0.0.0 listen [::] } target iqn.2012-06.com.example:target0 { auth-group no-authentication portal-group pg0 port ioctl/5/3 lun 0 { path /z/test.img size 8G } lun 1 { path /z/test1.img size 8G } } bhyve <...> -s 4,virtio-scsi,/dev/cam/ctl5.3,iid=3 <VM_NAME> From inside guest: root@:~ # zpool status test pool: test state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 dmesg: da0 at vtscsi0 bus 0 scbus0 target 0 lun 0 da0: <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-5 SCSI device da0: Serial Number MYSERIAL0000 da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 8192MB (16777216 512 byte sectors) da1 at vtscsi0 bus 0 scbus0 target 0 lun 1 da1: <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-5 SCSI device da1: Serial Number MYSERIAL0001 da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 8192MB (16777216 512 byte sectors) Discussed with: grehan Reviewed by: mav Obtained from: TrueOS Relnotes: Yes Sponsored by: iXsystems Inc. Tested with: FreeBSD HEAD, Fedora 28 (Workstation) and Ubuntu 18.04. Differential Revision: https://reviews.freebsd.org/D15276
2018-06-11 02:09:20 +00:00
ctl_scsi_all.c \
bhyve: Sort SRCS No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D40553
2023-06-15 16:21:54 +00:00
ctl_util.c \
Replay r349335 by scottl accidentally reverted by r349352 Add the PCI HDAudio device model from the 2016 GSoC. Detailed information can be found at https://wiki.freebsd.org/SummerOfCode2016/HDAudioEmulationForBhyve This commit has evolved from the original work to include Capsicum integration. As part of that, it only opens the host audio devices once and leaves them open, instead of opening and closing them on each guest access. Thanks to Peter Grehan and Marcelo Araujo for their help in bringing the work forward and providing some of the final techncial push. Submitted by: Alex Teaca <iateaca@freebsd.org> Differential Revision: D7840, D12419
2019-06-25 06:14:05 +00:00
hda_codec.c \
bhyve: Sort SRCS No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D40553
2023-06-15 16:21:54 +00:00
iov.c \
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
mem.c \
mevent.c \
bhyve: Split backends into separate files Currently the net_backend structure definition is private to net_backends.c, so all of the backend definitions are there. While adding a new backend to use libslirp, it was noted that this file is somewhat cluttered. Move the netmap and netgraph backends to their own files and clean up includes a bit. No functional change intended. Reviewed by: corvink, jhb MFC after: 3 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D42689
2023-11-22 19:10:27 +00:00
net_backend_netmap.c \
bhyve: Add a slirp network backend This enables a subset of the functionality provided by QEMU's user networking implementation. In particular, it uses net/libslirp, the same library as QEMU. libslirp is permissively licensed but has some dependencies which make it impractical to bring into the base system (glib in particular). I thus opted to make bhyve dlopen the libslirp.so, which can be installed via pkg. The library header is imported into bhyve. The slirp backend takes a "hostfwd" which is identical to QEMU's hostfwd. When configured, bhyve opens a host socket and listens for connections, which get forwarded to the guest. For instance, "hostfwd=tcp::1234-:22" allows one to ssh into the guest by ssh'ing to port 1234 on the host, e.g., via 127.0.0.1. I didn't try to hook up guestfwd support since I don't personally have a use-case for it yet, and I think it won't interact nicely with the capsicum sandbox. Reviewed by: jhb Tested by: rew MFC after: 1 month Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D42510
2023-11-22 19:11:03 +00:00
net_backend_slirp.c \
bhyve: abstraction for network backends Bhyve can currently emulate two virtual NICs, namely virtio-net and e1000, and connect to the host network through two backends, namely tap and netmap. However, there is no interface between virtual NIC functionalities and backend functionalities. As a result, the backend code is duplicated between the two virtual NIC implementations and also within the same virtual NIC. Also, e1000 cannot currently use netmap as a backend. This patch introduces a network backend API between virtio-net/e1000 and tap/netmap, to improve code reuse and add missing functionalities. Virtual NICs and backends can negotiate virtio-net features, such as checksum offload and TSO. If the backend supports the features, it will propagate this information to the guest, so that the latter can make use of them. Currently, only netmap VALE ports support the features, but support should be added to tap in the future. Reviewed by: jhb, bryanv MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D20659
2019-07-07 12:15:24 +00:00
net_backends.c \
bhyve: move common code to net_utils.c Both virtio_net and e82545 network frontends have code to validate and generate MAC addresses. These functionalities are replicated in the two files, so we move them in a separate compilation unit. Reviewed by: rgrimes, bryanv, imp, kevans MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D20626
2019-06-13 17:39:32 +00:00
net_utils.c \
bhyve: Support legacy PCI interrupts on arm64 This allows us to remove various #ifdef hacks and enable building more PCI devices. Note that a hole is left in the interrupt mapping for the RTC rather than having the two core devices straddle the PCIe interrupts. QEMU's virt machine also takes this approach. Reviewed by: jhb MFC after: 2 weeks Obtained from: CheriBSD
2024-02-17 01:44:51 +00:00
pci_ahci.c \
pci_e82545.c \
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
pci_emul.c \
bhyve: Support legacy PCI interrupts on arm64 This allows us to remove various #ifdef hacks and enable building more PCI devices. Note that a hole is left in the interrupt mapping for the RTC rather than having the two core devices straddle the PCIe interrupts. QEMU's virt machine also takes this approach. Reviewed by: jhb MFC after: 2 weeks Obtained from: CheriBSD
2024-02-17 01:44:51 +00:00
pci_hda.c \
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
pci_hostbridge.c \
bhyve: Support legacy PCI interrupts on arm64 This allows us to remove various #ifdef hacks and enable building more PCI devices. Note that a hole is left in the interrupt mapping for the RTC rather than having the two core devices straddle the PCIe interrupts. QEMU's virt machine also takes this approach. Reviewed by: jhb MFC after: 2 weeks Obtained from: CheriBSD
2024-02-17 01:44:51 +00:00
pci_irq.c \
- Add bhyve NVMe device emulation. The initial work on bhyve NVMe device emulation was done by the GSoC student Shunsuke Mie and was heavily modified in performan, functionality and guest support by Leon Dang. bhyve: -s <n>,nvme,devpath,maxq=#,qsz=#,ioslots=#,sectsz=#,ser=A-Z accepted devpath: /dev/blockdev /path/to/image ram=size_in_MiB Tested with guest OS: FreeBSD Head, Linux Fedora fc27, Ubuntu 18.04, OpenSuse 15.0, Windows Server 2016 Datacenter. Tested with all accepted device paths: Real nvme, zdev and also with ram. Tested on: AMD Ryzen Threadripper 1950X 16-Core Processor and Intel(R) Xeon(R) CPU E5-2609 v2 @ 2.50GHz. Tests at: https://people.freebsd.org/~araujo/bhyve_nvme/nvme.txt Submitted by: Shunsuke Mie <sux2mfgj_gmail.com>, Leon Dang <leon_digitalmsx.com> Reviewed by: chuck (early version), grehan Relnotes: Yes Sponsored by: iXsystems Inc. Differential Revision: https://reviews.freebsd.org/D14022
2018-07-05 03:33:58 +00:00
pci_nvme.c \
bhyve: Support legacy PCI interrupts on arm64 This allows us to remove various #ifdef hacks and enable building more PCI devices. Note that a hole is left in the interrupt mapping for the RTC rather than having the two core devices straddle the PCIe interrupts. QEMU's virt machine also takes this approach. Reviewed by: jhb MFC after: 2 weeks Obtained from: CheriBSD
2024-02-17 01:44:51 +00:00
pci_uart.c \
Add virtio-9p (aka VirtFS) filesystem sharing to bhyve. VirtFS allows sharing an arbitrary directory tree between bhyve virtual machine and the host. Current implementation has a fairly complete support for 9P2000.L protocol, except for the extended attribute support. It has been verified to work with the qemu-kvm hypervisor. Reviewed by: rgrimes, emaste, jhb, trasz Approved by: trasz (mentor) MFC after: 1 month Relnotes: yes Sponsored by: Conclusive Engineering (development), vStack.com (funding) Differential Revision: https://reviews.freebsd.org/D10335
2020-10-03 19:05:13 +00:00
pci_virtio_9p.c \
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
pci_virtio_block.c \
Add virtio-console support to bhyve. Adds virtio-console device support to bhyve, allowing to create bidirectional character streams between host and guest. Syntax: -s <slotnum>,virtio-console,port1=/path/to/port1.sock,anotherport=... Maximum of 16 ports per device can be created. Every port is named and corresponds to an Unix domain socket created by bhyve. bhyve accepts at most one connection per port at a time. Limitations: - due to lack of destructors of in bhyve, sockets on the filesystem must be cleaned up manually after bhyve exits - there's no way to use "console port" feature, nor the console port resize as of now - emergency write is advertised, but no-op as of now Approved by: trasz MFC after: 1 month Relnotes: yes Sponsored by: iXsystems, Inc. Differential Revision: D7185
2016-09-17 13:48:01 +00:00
pci_virtio_console.c \
Add a virtio-input device emulation. This will be used to inject keyboard/mouse input events into a guest. The command line syntax is: -s <slot>,virtio-input,/dev/input/eventX Reviewed by: jhb (bhyve), grehan Obtained from: Corvin Köhne <C.Koehne@beckhoff.com> MFC after: 3 weeks Relnotes: yes Differential Revision: https://reviews.freebsd.org/D30020
2021-06-08 08:56:43 +00:00
pci_virtio_input.c \
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
pci_virtio_net.c \
Add support for the virtio RNG entropy-source device. Call through to /dev/random synchronously to fill virtio buffers with RNG data. Tested with FreeBSD-CURRENT and Ubuntu guests. Submitted by: Leon Dang Discussed with: markm MFC after: 3 weeks Sponsored by: Nahanni Systems
2014-04-02 20:18:17 +00:00
pci_virtio_rnd.c \
- Add bhyve virtio-scsi storage backend support. Example of configuration: ctl.conf: portal-group pg0 { discovery-auth-group no-authentication listen 0.0.0.0 listen [::] } target iqn.2012-06.com.example:target0 { auth-group no-authentication portal-group pg0 port ioctl/5/3 lun 0 { path /z/test.img size 8G } lun 1 { path /z/test1.img size 8G } } bhyve <...> -s 4,virtio-scsi,/dev/cam/ctl5.3,iid=3 <VM_NAME> From inside guest: root@:~ # zpool status test pool: test state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 dmesg: da0 at vtscsi0 bus 0 scbus0 target 0 lun 0 da0: <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-5 SCSI device da0: Serial Number MYSERIAL0000 da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 8192MB (16777216 512 byte sectors) da1 at vtscsi0 bus 0 scbus0 target 0 lun 1 da1: <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-5 SCSI device da1: Serial Number MYSERIAL0001 da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 8192MB (16777216 512 byte sectors) Discussed with: grehan Reviewed by: mav Obtained from: TrueOS Relnotes: Yes Sponsored by: iXsystems Inc. Tested with: FreeBSD HEAD, Fedora 28 (Workstation) and Ubuntu 18.04. Differential Revision: https://reviews.freebsd.org/D15276
2018-06-11 02:09:20 +00:00
pci_virtio_scsi.c \
bhyve: Support legacy PCI interrupts on arm64 This allows us to remove various #ifdef hacks and enable building more PCI devices. Note that a hole is left in the interrupt mapping for the RTC rather than having the two core devices straddle the PCIe interrupts. QEMU's virt machine also takes this approach. Reviewed by: jhb MFC after: 2 weeks Obtained from: CheriBSD
2024-02-17 01:44:51 +00:00
pci_xhci.c \
bhyve: add cmdline option to enable qemu's fwcfg Let the user decide if he wants to use bhyve's fwctl or qemu's fwcfg. He can set the interface by adding a fwcfg option to bootrom: -l bootrom,<path/to/rom>,fwcfg=bhyve -l bootrom,<path/to/rom>,fwcfg=qemu Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D38337
2021-08-18 07:31:59 +00:00
qemu_fwcfg.c \
bhyve: add helper struct for qemus acpi table loader The hypervisor is aware of all system properties. For the guest bios it's hard and complex to detect all system properties. For that reason, it would be better if the hypervisor creates acpi tables instead of the guest. Therefore, the hypervisor has to send the acpi tables to the guest. At the moment, bhyve just copies the acpi tables into the guest memory. This approach has some restrictions. You have to keep sure that the guest doesn't overwrite them accidentally. Additionally, the size of acpi tables is limited. Providing a plain copy of all acpi tables by fwcfg isn't possible. Acpi tables have to point to each other. So, if the guest copies the acpi tables into memory by it's own, it has to patch the tables. Due to different layouts for different acpi tables, there's no generic way to do that. For that reason, qemu created a table loader interface. It contains commands for the guest for loading specific blobs into guest memory and patching those blobs. This commit adds a qemu_loader class which handles the creation of qemu loader commands. At the moment, the WRITE_POINTER command isn't implement. It won't be required by bhyve's acpi table generation yet. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D38438
2022-04-06 09:10:36 +00:00
qemu_loader.c \
Add SMBIOS support. A new option, -U, can be used to set the UUID in the System Information (Type 1) structure. Manpage fix to follow. Approved by: grehan (co-mentor)
2014-03-04 17:12:06 +00:00
smbiostbl.c \
Import bhyve_graphics into CURRENT. Thanks to all who tested this on the branch. Original commit message: Initial bhyve native graphics support. This adds emulations for a raw framebuffer device, PS2 keyboard/mouse, XHCI USB controller and a USB tablet. A simple VNC server is provided for keyboard/mouse input, and graphics output. A VGA emulation is included, but is currently disconnected until an additional bhyve change to block out VGA memory is committed. Credits: - raw framebuffer, VNC server, XHCI controller, USB bus/device emulation and UEFI f/w support by Leon Dang - VGA, console/g, initial VNC server by tychon@ - PS2 keyboard/mouse jointly done by tychon@ and Leon Dang - hypervisor framebuffer mem support by neel@ Tested by: Michael Dexter, in a number of revisions of this code. With the appropriate UEFI image, FreeBSD, Windows and Linux guests can installed and run in graphics mode using the UEFI/GOP framebuffer. Approved by: re (gjb)
2016-07-04 03:19:06 +00:00
sockstream.c \
bhyve: add basic TPM device Add an empty TPM device struct which will be used for TPM emulation in subsequent commits. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D40452
2023-05-15 11:00:06 +00:00
tpm_device.c \
bhyve: add basic TPM passthrough emulation At the moment, the emulation only opens a file descriptor to the TPM device. Some subsequent commits will read and write from it. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D40455
2023-05-15 12:04:15 +00:00
tpm_emul_passthru.c \
bhyve: add basic CRB interface for TPM devices Add a basic emulation for the command and response buffer interface of TPM devices. This commit only implements some CRB register and resets them. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D40456
2022-08-29 10:10:43 +00:00
tpm_intf_crb.c \
bhyve: add Qemu PPI emulation for TPM devices Windows requires a physical presence interface to recognize the TPM device. Qemu's OVMF has an implementation for the PPI which can be reused. Using the Qemu PPI makes it very easy because we don't have to implement new PPI functionality into our OVMF. The Qemu implementation is already there. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D40462
2022-08-29 10:10:47 +00:00
tpm_ppi_qemu.c \
bhyve: Move device model-independent UART code into a separate file Currently bhyve implements a ns16550-compatible UART in uart_emul.c. This file also contains generic code to manage RX FIFOs and to handle reading from and writing to a TTY. bhyve instantiates UARTs to implement COM devices (via pci_lpc.c) and PCI UART devices. The arm64 port will bring with it a PL011 device model which is used as the default console (i.e., no COM ports). To simplify its integration, add a UART "backend" layer which lets UART device models allocate an RX FIFO and interact with TTYs without duplicating code. In particular, code in uart_backend.* is to be shared among device models, and the namespace for uart_emul.* is changed to uart_ns16550_*. This is based on andrew@'s work in https://github.com/zxombie/freebsd/tree/bhyvearm64 but I've made a number of changes, particularly with respect to naming and source code organization. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40993
2024-03-21 04:20:37 +00:00
uart_backend.c \
Cosmetic change - switch over to vertical SRCS to make it easier to keep files in alpha order. Reviewed by: neel
2014-01-03 19:31:40 +00:00
uart_emul.c \
Import bhyve_graphics into CURRENT. Thanks to all who tested this on the branch. Original commit message: Initial bhyve native graphics support. This adds emulations for a raw framebuffer device, PS2 keyboard/mouse, XHCI USB controller and a USB tablet. A simple VNC server is provided for keyboard/mouse input, and graphics output. A VGA emulation is included, but is currently disconnected until an additional bhyve change to block out VGA memory is committed. Credits: - raw framebuffer, VNC server, XHCI controller, USB bus/device emulation and UEFI f/w support by Leon Dang - VGA, console/g, initial VNC server by tychon@ - PS2 keyboard/mouse jointly done by tychon@ and Leon Dang - hypervisor framebuffer mem support by neel@ Tested by: Michael Dexter, in a number of revisions of this code. With the appropriate UEFI image, FreeBSD, Windows and Linux guests can installed and run in graphics mode using the UEFI/GOP framebuffer. Approved by: re (gjb)
2016-07-04 03:19:06 +00:00
usb_emul.c \
usb_mouse.c \
bhyve: Sort SRCS No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D40553
2023-06-15 16:21:54 +00:00
virtio.c \
bhyve: Split vmexit handling into a separate file Put it in amd64, since most of it is MD and won't be used on arm64. Add a bit of glue to bhyverun.h to make CPU startup and shutdown work without having to export more global variables. AP startup will be reworked further in a future revision. This makes bhyverun.c much more machine-independent. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40556
2023-10-04 16:22:56 +00:00
vmexit.c \
bhyve: Move MSR emulation into amd64/ No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40733
2023-10-04 16:23:22 +00:00
vmgenc.c
Import of bhyve hypervisor and utilities, part 1. vmm.ko - kernel module for VT-x, VT-d and hypervisor control bhyve - user-space sequencer and i/o emulation vmmctl - dump of hypervisor register state libvmm - front-end to vmm.ko chardev interface bhyve was designed and implemented by Neel Natu. Thanks to the following folk from NetApp who helped to make this available: Joe CaraDonna Peter Snyder Jeff Heller Sandeep Mann Steve Miller Brian Pawlowski
2011-05-13 04:54:01 +00:00
Initial support for bhyve save and restore. Save and restore (also known as suspend and resume) permits a snapshot to be taken of a guest's state that can later be resumed. In the current implementation, bhyve(8) creates a UNIX domain socket that is used by bhyvectl(8) to send a request to save a snapshot (and optionally exit after the snapshot has been taken). A snapshot currently consists of two files: the first holds a copy of guest RAM, and the second file holds other guest state such as vCPU register values and device model state. To resume a guest, bhyve(8) must be started with a matching pair of command line arguments to instantiate the same set of device models as well as a pointer to the saved snapshot. While the current implementation is useful for several uses cases, it has a few limitations. The file format for saving the guest state is tied to the ABI of internal bhyve structures and is not self-describing (in that it does not communicate the set of device models present in the system). In addition, the state saved for some device models closely matches the internal data structures which might prove a challenge for compatibility of snapshot files across a range of bhyve versions. The file format also does not currently support versioning of individual chunks of state. As a result, the current file format is not a fixed binary format and future revisions to save and restore will break binary compatiblity of snapshot files. The goal is to move to a more flexible format that adds versioning, etc. and at that point to commit to providing a reasonable level of compatibility. As a result, the current implementation is not enabled by default. It can be enabled via the WITH_BHYVE_SNAPSHOT=yes option for userland builds, and the kernel option BHYVE_SHAPSHOT. Submitted by: Mihai Tiganus, Flavius Anton, Darius Mihai Submitted by: Elena Mihailescu, Mihai Carabas, Sergiu Weisz Relnotes: yes Sponsored by: University Politehnica of Bucharest Sponsored by: Matthew Grooms (student scholarships) Sponsored by: iXsystems Differential Revision: https://reviews.freebsd.org/D19495
2020-05-05 00:02:04 +00:00
.if ${MK_BHYVE_SNAPSHOT} != "no"
SRCS+= snapshot.c
.endif
bhyve: Start moving machine-dependent code into subdirectories In preparation for an arm64 port, make an easy change which puts some machine-dependent code in its own directory. Going forward, code which is only used on one platform should live in a MD directory. We should strive to layer modules in such a way as to avoid polluting shared code with lots of ifdefs. For some existing files this will take some effort. task_switch.c and fwctl.c are an easy place to start: the former is very x86-specific, and the latter provides an I/O port interface which can't be used on anything other than x86. (fwcfg as implemented has the same problem, but QEMU also supports a MMIO fwcfg interface.) So I propose that we start by simply making those files conditional. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40501
2023-10-04 16:20:37 +00:00
.include "${MACHINE_CPUARCH}/Makefile.inc"
bhyve: Provide optional libfdt linking The arm64 port currently does not support ACPI, it instead builds up an FDT which is exported to the guest. This mechanism will not be used on amd64 but isn't really arm64-specific either, so provide an opt-in mechanism to link libfdt. No functional change intended. Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40995
2024-04-03 16:48:45 +00:00
.if defined(BHYVE_FDT_SUPPORT)
LIBADD+= fdt
CFLAGS+= -I${SRCTOP}/sys/contrib/libfdt
.endif
bhyve: Make gdb support optional Add a BHYVE_GDB_SUPPORT make variable that can be set by per-arch makefiles. When set, BHYVE_GDB is defined and can be used as a preprocessor predicate. Use it to guard gdb stub calls in MI code. The arm64 bhyve port currently does not have a functional gdb stub, but that's not critical to landing the port, so this mechanism slightly reduces the friction of adding support for a new platform. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40986
2023-10-04 16:26:36 +00:00
.if defined(BHYVE_GDB_SUPPORT)
SRCS+= gdb.c
CFLAGS+= -DBHYVE_GDB
.ifdef GDB_LOG
CFLAGS+=-DGDB_LOG
.endif
bhyve: Add support for XML register definitions This is useful for exposing additional registers to debuggers. For instance, control registers are now available on amd64 when using gdb to debug a guest. The stub indicates support by including the string "qXfer:features:read+" in its feature list. The debugger queries for target descriptions by sending the query "qXfer:features:read:" followed by a file path. The XML definitions are copied from QEMU and installed to /usr/share/bhyve/gdb. Note that we currently don't handle the SIMD registers at all, since that's of somewhat limited utility (for me at least) and since that requires new ioctls to fetch the register values. Reviewed by: jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D43666
2024-02-21 00:21:29 +00:00
SUBDIR+= gdb
bhyve: Make gdb support optional Add a BHYVE_GDB_SUPPORT make variable that can be set by per-arch makefiles. When set, BHYVE_GDB is defined and can be used as a preprocessor predicate. Use it to guard gdb stub calls in MI code. The arm64 bhyve port currently does not have a functional gdb stub, but that's not critical to landing the port, so this mechanism slightly reduces the friction of adding support for a new platform. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40986
2023-10-04 16:26:36 +00:00
.endif
bhyve: Start moving machine-dependent code into subdirectories In preparation for an arm64 port, make an easy change which puts some machine-dependent code in its own directory. Going forward, code which is only used on one platform should live in a MD directory. We should strive to layer modules in such a way as to avoid polluting shared code with lots of ifdefs. For some existing files this will take some effort. task_switch.c and fwctl.c are an easy place to start: the former is very x86-specific, and the latter provides an I/O port interface which can't be used on anything other than x86. (fwcfg as implemented has the same problem, but QEMU also supports a MMIO fwcfg interface.) So I propose that we start by simply making those files conditional. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40501
2023-10-04 16:20:37 +00:00
CFLAGS+=-I${.CURDIR} \
-I${.CURDIR}/../../contrib/lib9p \
-I${SRCTOP}/sys
Revamp the x86 instruction emulation in bhyve. On a nested page table fault the hypervisor will: - fetch the instruction using the guest %rip and %cr3 - decode the instruction in 'struct vie' - emulate the instruction in host kernel context for local apic accesses - any other type of mmio access is punted up to user-space (e.g. ioapic) The decoded instruction is passed as collateral to the user-space process that is handling the PAGING exit. The emulation code is fleshed out to include more addressing modes (e.g. SIB) and more types of operands (e.g. imm8). The source code is unified into a single file (vmm_instruction_emul.c) that is compiled into vmm.ko as well as /usr/sbin/bhyve. Reviewed by: grehan Obtained from: NetApp
2012-11-28 00:02:17 +00:00
bhyve: Provide optional libfdt linking The arm64 port currently does not support ACPI, it instead builds up an FDT which is exported to the guest. This mechanism will not be used on amd64 but isn't really arm64-specific either, so provide an opt-in mechanism to link libfdt. No functional change intended. Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40995
2024-04-03 16:48:45 +00:00
LIBADD+= vmmapi md nv pthread z util sbuf cam 9p
bhyve: fix build without casper/capsicum support PR: 252353
2021-01-03 16:18:22 +00:00
Initial support for bhyve save and restore. Save and restore (also known as suspend and resume) permits a snapshot to be taken of a guest's state that can later be resumed. In the current implementation, bhyve(8) creates a UNIX domain socket that is used by bhyvectl(8) to send a request to save a snapshot (and optionally exit after the snapshot has been taken). A snapshot currently consists of two files: the first holds a copy of guest RAM, and the second file holds other guest state such as vCPU register values and device model state. To resume a guest, bhyve(8) must be started with a matching pair of command line arguments to instantiate the same set of device models as well as a pointer to the saved snapshot. While the current implementation is useful for several uses cases, it has a few limitations. The file format for saving the guest state is tied to the ABI of internal bhyve structures and is not self-describing (in that it does not communicate the set of device models present in the system). In addition, the state saved for some device models closely matches the internal data structures which might prove a challenge for compatibility of snapshot files across a range of bhyve versions. The file format also does not currently support versioning of individual chunks of state. As a result, the current file format is not a fixed binary format and future revisions to save and restore will break binary compatiblity of snapshot files. The goal is to move to a more flexible format that adds versioning, etc. and at that point to commit to providing a reasonable level of compatibility. As a result, the current implementation is not enabled by default. It can be enabled via the WITH_BHYVE_SNAPSHOT=yes option for userland builds, and the kernel option BHYVE_SHAPSHOT. Submitted by: Mihai Tiganus, Flavius Anton, Darius Mihai Submitted by: Elena Mihailescu, Mihai Carabas, Sergiu Weisz Relnotes: yes Sponsored by: University Politehnica of Bucharest Sponsored by: Matthew Grooms (student scholarships) Sponsored by: iXsystems Differential Revision: https://reviews.freebsd.org/D19495
2020-05-05 00:02:04 +00:00
.if ${MK_BHYVE_SNAPSHOT} != "no"
LIBADD+= ucl xo
.endif
Import bhyve_graphics into CURRENT. Thanks to all who tested this on the branch. Original commit message: Initial bhyve native graphics support. This adds emulations for a raw framebuffer device, PS2 keyboard/mouse, XHCI USB controller and a USB tablet. A simple VNC server is provided for keyboard/mouse input, and graphics output. A VGA emulation is included, but is currently disconnected until an additional bhyve change to block out VGA memory is committed. Credits: - raw framebuffer, VNC server, XHCI controller, USB bus/device emulation and UEFI f/w support by Leon Dang - VGA, console/g, initial VNC server by tychon@ - PS2 keyboard/mouse jointly done by tychon@ and Leon Dang - hypervisor framebuffer mem support by neel@ Tested by: Michael Dexter, in a number of revisions of this code. With the appropriate UEFI image, FreeBSD, Windows and Linux guests can installed and run in graphics mode using the UEFI/GOP framebuffer. Approved by: re (gjb)
2016-07-04 03:19:06 +00:00
Allow the bhyve VNC server to listen on IPv6 for incoming connections. Alternatively to IPv4 address:port this will allow to listen on IPv6 link-local (incl. scope), a specific address, or ::. Addresses have to be given in RFC2732 format so that [::]:port parsing will work. This patch also starts to introduce WITH_INET/INET6_SUPPORT to bhyve. PR: 232018 Submitted by: Dave Rush (northwoodlogic.free gmail.com) (original) Reviewed by: Dave Rush (updated verison) MFC after: 3 days
2018-10-24 08:45:33 +00:00
.if ${MK_INET_SUPPORT} != "no"
CFLAGS+=-DINET
.endif
.if ${MK_INET6_SUPPORT} != "no"
CFLAGS+=-DINET6
.endif
Add a new bhyve network backend that allow to connect the VM to the netgraph(4) network. The backend uses the socket API with the PF_NETGRAPH protocol family, which is provided by the ng_socket(4). To use the new backend, provide the following bhyve option: -s X:Y:Z,[virtio-net|e1000],netgraph,socket=[ng_socket name],path=[destination node],hook=[our socket src hook],peerhook=[dst node hook] Reviewed by: vmaffione, lutz_donnerhacke.de Approved by: vmaffione (mentor) Sponsored by: vstack.com Differential Revision: https://reviews.freebsd.org/D24620
2020-05-12 11:18:14 +00:00
.if ${MK_NETGRAPH_SUPPORT} != "no"
bhyve: Split backends into separate files Currently the net_backend structure definition is private to net_backends.c, so all of the backend definitions are there. While adding a new backend to use libslirp, it was noted that this file is somewhat cluttered. Move the netmap and netgraph backends to their own files and clean up includes a bit. No functional change intended. Reviewed by: corvink, jhb MFC after: 3 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D42689
2023-11-22 19:10:27 +00:00
SRCS+= net_backend_netgraph.c
LIBADD+= netgraph
Add a new bhyve network backend that allow to connect the VM to the netgraph(4) network. The backend uses the socket API with the PF_NETGRAPH protocol family, which is provided by the ng_socket(4). To use the new backend, provide the following bhyve option: -s X:Y:Z,[virtio-net|e1000],netgraph,socket=[ng_socket name],path=[destination node],hook=[our socket src hook],peerhook=[dst node hook] Reviewed by: vmaffione, lutz_donnerhacke.de Approved by: vmaffione (mentor) Sponsored by: vstack.com Differential Revision: https://reviews.freebsd.org/D24620
2020-05-12 11:18:14 +00:00
.endif
Add VNC Authentication support based on RFC6143 section 7.2.2. Submitted by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de> Reworked by: myself Reviewed by: grehan, rgrimes and jilles MFC after: 1 week. Relnotes: Yes. Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D10818
2017-06-02 02:35:16 +00:00
.if ${MK_OPENSSL} == "no"
CFLAGS+=-DNO_OPENSSL
.else
LIBADD+= crypto
bhyve: specify OpenSSL 1.1 API OPENSSL_API_COMPAT can be used to specify the OpenSSL API version in use for the purpose of hiding deprecated interfaces and enabling the appropriate deprecation notices. This change is a NFC while we're still using OpenSSL 1.1.1 but will avoid deprecation warnings upon the switch to OpenSSL 3.0. A future change can then switch bhyve to use OpenSSL 3.0 APIs. Reviewed by: jhb Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39998
2023-05-08 12:09:26 +00:00
CFLAGS+=-DOPENSSL_API_COMPAT=0x10100000L
Add VNC Authentication support based on RFC6143 section 7.2.2. Submitted by: Fabian Freyer <fabian.freyer@physik.tu-berlin.de> Reworked by: myself Reviewed by: grehan, rgrimes and jilles MFC after: 1 week. Relnotes: Yes. Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D10818
2017-06-02 02:35:16 +00:00
.endif
Add emulation for Intel e1000 (e82545) network adapter. The code was successfully tested with FreeBSD, Linux, Solaris and Windows guests. This interface is predictably slower (about 2x) then virtio-net, but it is very helpful for guests not supporting virtio-net by default. Thanks to Jeremiah Lott and Peter Grehan for doing original heavy lifting.
2016-07-09 20:41:59 +00:00
CFLAGS+= -I${BHYVE_SYSDIR}/sys/dev/e1000
CFLAGS+= -I${BHYVE_SYSDIR}/sys/dev/mii
Import bhyve_graphics into CURRENT. Thanks to all who tested this on the branch. Original commit message: Initial bhyve native graphics support. This adds emulations for a raw framebuffer device, PS2 keyboard/mouse, XHCI USB controller and a USB tablet. A simple VNC server is provided for keyboard/mouse input, and graphics output. A VGA emulation is included, but is currently disconnected until an additional bhyve change to block out VGA memory is committed. Credits: - raw framebuffer, VNC server, XHCI controller, USB bus/device emulation and UEFI f/w support by Leon Dang - VGA, console/g, initial VNC server by tychon@ - PS2 keyboard/mouse jointly done by tychon@ and Leon Dang - hypervisor framebuffer mem support by neel@ Tested by: Michael Dexter, in a number of revisions of this code. With the appropriate UEFI image, FreeBSD, Windows and Linux guests can installed and run in graphics mode using the UEFI/GOP framebuffer. Approved by: re (gjb)
2016-07-04 03:19:06 +00:00
CFLAGS+= -I${BHYVE_SYSDIR}/sys/dev/usb/controller
Initial support for bhyve save and restore. Save and restore (also known as suspend and resume) permits a snapshot to be taken of a guest's state that can later be resumed. In the current implementation, bhyve(8) creates a UNIX domain socket that is used by bhyvectl(8) to send a request to save a snapshot (and optionally exit after the snapshot has been taken). A snapshot currently consists of two files: the first holds a copy of guest RAM, and the second file holds other guest state such as vCPU register values and device model state. To resume a guest, bhyve(8) must be started with a matching pair of command line arguments to instantiate the same set of device models as well as a pointer to the saved snapshot. While the current implementation is useful for several uses cases, it has a few limitations. The file format for saving the guest state is tied to the ABI of internal bhyve structures and is not self-describing (in that it does not communicate the set of device models present in the system). In addition, the state saved for some device models closely matches the internal data structures which might prove a challenge for compatibility of snapshot files across a range of bhyve versions. The file format also does not currently support versioning of individual chunks of state. As a result, the current file format is not a fixed binary format and future revisions to save and restore will break binary compatiblity of snapshot files. The goal is to move to a more flexible format that adds versioning, etc. and at that point to commit to providing a reasonable level of compatibility. As a result, the current implementation is not enabled by default. It can be enabled via the WITH_BHYVE_SNAPSHOT=yes option for userland builds, and the kernel option BHYVE_SHAPSHOT. Submitted by: Mihai Tiganus, Flavius Anton, Darius Mihai Submitted by: Elena Mihailescu, Mihai Carabas, Sergiu Weisz Relnotes: yes Sponsored by: University Politehnica of Bucharest Sponsored by: Matthew Grooms (student scholarships) Sponsored by: iXsystems Differential Revision: https://reviews.freebsd.org/D19495
2020-05-05 00:02:04 +00:00
.if ${MK_BHYVE_SNAPSHOT} != "no"
CFLAGS+= -I${SRCTOP}/contrib/libucl/include
CFLAGS+= -DBHYVE_SNAPSHOT
.endif
Import of bhyve hypervisor and utilities, part 1. vmm.ko - kernel module for VT-x, VT-d and hypervisor control bhyve - user-space sequencer and i/o emulation vmmctl - dump of hypervisor register state libvmm - front-end to vmm.ko chardev interface bhyve was designed and implemented by Neel Natu. Thanks to the following folk from NetApp who helped to make this available: Joe CaraDonna Peter Snyder Jeff Heller Sandeep Mann Steve Miller Brian Pawlowski
2011-05-13 04:54:01 +00:00
bhyve: Disable thread safety analysis The warnings that arise are bogus and have to be muted with __no_lock_analysis in most cases. As a step towards enabling the default warning level for bhyve, just disable them. Reviewed by: corvink, jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D37295
2022-11-18 19:04:19 +00:00
# Disable thread safety analysis since it only finds very simple bugs and
# yields many false positives.
NO_WTHREAD_SAFETY=
bhyve: Enable the default compiler warnings Disable -Wcast-align for now since we have many instances of that warning (I fixed some but not most of them) and platforms on which bhyve runs don't particularly care about unaligned accesses. Reviewed by: corvink Differential Revision: https://reviews.freebsd.org/D37296
2022-11-18 19:10:33 +00:00
NO_WCAST_ALIGN=
Import of bhyve hypervisor and utilities, part 1. vmm.ko - kernel module for VT-x, VT-d and hypervisor control bhyve - user-space sequencer and i/o emulation vmmctl - dump of hypervisor register state libvmm - front-end to vmm.ko chardev interface bhyve was designed and implemented by Neel Natu. Thanks to the following folk from NetApp who helped to make this available: Joe CaraDonna Peter Snyder Jeff Heller Sandeep Mann Steve Miller Brian Pawlowski
2011-05-13 04:54:01 +00:00
.include <bsd.prog.mk>
Reference in a new issue Copy permalink