aboutsummaryrefslogtreecommitdiff
path: root/usr.sbin/bhyve/amd64
Commit message (Collapse)AuthorAgeFilesLines
* bhyve: Add SPDX-License-Identifier tagTuukka Pasanen2026-02-201-0/+2
| | | | | Reviewed by: emaste Sponsored by: The FreeBSD Foundation
* bhyve: Use PCIOCGETCONF to find the host LPC bridgeMark Johnston2026-01-261-32/+47
| | | | | | | | | | | | | | | | | | | | pci_host_read_config() requires write access to /dev/pci so cannot be used with unprivileged bhyve. The lpc init code uses it to find the host system's LPC bridge device and so was generating warnings with bhyve running as a non-root user. Refactor the implementation to use PCIOCGETCONF instead, which doesn't require any special privileges. This isn't formally necessary, as we only care about copying the host system's identifiers in order to support Intel GPU passthrough (see commit f4ceaff56ddaa), but it's straightforward and lets an unprivileged user run bhyve without seeing warnings about failing to open /dev/pci with write permissions. Reviewed by: corvink, rew MFC after: 3 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54851
* bhyve: Introduce monitor modeBojan Novković2025-12-171-2/+6
| | | | | | | | | | | | | | | | | | | | | This change introduces "monitor mode", a mechanism for automatically releasing virtual machine resources when bhyve dies, bringing us closer towards making non-root bhyve viable. Under this regime bhyve will create a transient virtual machine using `vmmctl`'s `VMMCTL_CREATE_DESTROY_ON_CLOSE` flag and automatically reboot said virtual machine as long as it exits with "reboot" status. This is done by splitting bhyve into two processes. The parent process creates the virtual machine while the child process initializes and runs the virtual machine. When the child exits the parent inspects its exit status and either exits or forks again. `vmmctl` automatically destroys the underlying virtual machine once the parent process dies. Differential Revision: https://reviews.freebsd.org/D53731 Reviewed by: markj Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. MFC after: 3 months
* bhyve: Eliminate exit status magic numbersBojan Novković2025-12-173-10/+10
| | | | | | | | | | | | | | | bhyve's exit status codes indicate how the VM was terminated. Unfortunately, their meaning within the source code is somewhat unclear since they are only used as magic numbers. Fix this by defining exit status macros and using them to replace the magic numbers in exit(3) function calls. Differential Revision: https://reviews.freebsd.org/D53730 Reviewed by: markj, corvink, emaste Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. MFC after: 3 months
* bhyve: assign a valid INTPIN to NVIDIA GPUsCorvin Köhne2025-09-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | When passing an NVIDIA GPU to a Linux VM, the GPU driver refuses to work and complains about a missing IRQ: [ 77.208984] NVRM: Can't find an IRQ for your NVIDIA card! [ 77.212697] NVRM: Please check your BIOS settings. [ 77.212699] NVRM: [Plug & Play OS] should be set to NO [ 77.212700] NVRM: [Assign IRQ to VGA] should be set to YES [ 77.212702] nvidia: probe of 0000:00:07.0 failed with error -1 By setting a valid INTPIN in the PCI config space those error messages disappear. Additionally, tools like nvidia-smi are able to detect the GPU and the GPU driver seems to work properly. Note that bhyve still doesn't support legacy interrupts. So, the guest shouldn't try to use it even though we're assigning an INTPIN. Reviewed by: jhb Tested by: chuck MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D51892
* vmm: Suspend the VM before destroying itMark Johnston2025-09-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we don't do anything to kick vcpu threads out of a sleep state when destroying a VM. For instance, suppose a guest executes hlt on amd64 or wfi on arm64 with interrupts disabled. Then, bhyvectl --destroy will hang until the vcpu thread somehow comes out of vm_handle_hlt()/vm_handle_wfi() since destroy_dev() is waiting for vCPU threads to drain. Note that on amd64, if hw.vmm.halt_detection is set to 1 (the default), the guest will automatically exit in this case since it's treated as a shutdown. But, the above should not hang if halt_detection is set to 0. Here, vm_suspend() wakes up vcpu threads, and a subsequent attempt to run the vCPU will result in an error which gets propagated to userspace, allowing destroy_dev() to proceed. Add a new suspend code for this purpose. Modify bhyve to exit with status 4 ("exited due to an error") when it's received, since that's what'll happen generally when the VM is destroyed asynchronously. Reported by: def MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D51761
* bhyve: protect MMIO mapped BDSM registerCorvin Köhne2025-08-051-0/+45
| | | | | | | | | | | The Windows graphics driver reads the value of the BDSM register from MMIO space. This value makes no sense in our virtual environment because it's a host address. Therefore, we have to trap and emulate it. Reviewed by: jhb MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D45342
* bhyve: add GVT-d support for graphics gen 11 and newerCorvin Köhne2025-08-051-0/+37
| | | | | | | | | | | | | The BDSM (Base Data Stolen Memory) register changed. Older generations are using a 32 bit register. On newer generations a different register address is used and the size was changed to 64 bit to permit allocating graphics stolen memory above 4 GB. Bhyve has to detect that and properly emulate the correct register. Reviewed by: jhb, markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D45338
* bhyve: scan PCI device ID to properly set BDSM addressCorvin Köhne2025-08-051-6/+92
| | | | | | | | | | | | | | | | The address and size of the BDSM register has changed in recent Intel GPUs. To account for that change, we have to detect the GPU generation. We've recently added all known PCI IDs of Intel GPUs from Linux. Make use of this header to scan the device ID and properly set the BDSM address. Note that even though a bunch of devices is listed in our device array, not all device will work properly. Especially some old devices may not support VT-d, required for passthrough in general, at all. Reviewed by: jhb MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D50807
* bhyve: Add support for specifying guest NUMA configurationBojan Novković2025-07-271-2/+12
| | | | | | | | | | | | | | | | | | | | | This patch adds basic support for adding NUMA domains to a bhyve VM. The user can define a NUMA domain using the -n flag, which expects a domain id, a CPU set, and memory size for each NUMA domain. After parsing the node configurations, we use the interfaces added in previous patches to set the NUMA configuration for the virtual machine. Afterwards, we use the configuration to build the ACPI 'Static Resource Affinity Table' (SRAT) which is used to pass NUMA information to the guest. Users can optionally configure domainset(9) allocation policies for each domain. Since each NUMA domain is essentially a separate system memory segment, we can parse user-provided domainset(9) policies and install them into its backing 'vm_object'. Differential Revision: https://reviews.freebsd.org/D44567 Reviewed by: markj Relnotes: yes
* bhyve: Report SVM as disabled on AMDChuck Tuffli2025-07-261-0/+9
| | | | | | | | | | | | | | | | | bhyve with a Windows 2025 guest will hang/freeze with the message rdmsr to register 0xc0010114 on a system with an AMD Ryzen 5. Evidently, recent versions of Windows ignore the CPUID bits and still read this MSR. Fix is to report Secure Virtual Machine (SVM) mode as disabled in the VM CR. PR: 288308 Reported by: demik+freebsd@lostwave.net Tested by: demik+freebsd@lostwave.net Obtained from: Illumos MFC after: 1 week Reviewed by: avg, markj, jhb Differential Revision: https://reviews.freebsd.org/D51480
* bhyve: support VBTs which lay outside of the OpRegionCorvin Köhne2025-06-241-0/+112
| | | | | | | | | | | | | | | | | | | | | | Previously, all of our devices had an OpRegion with a VBT which lays inside the OpRegion. Unfortunately, the OpRegion has a fixed size and VBTs get more and more features/settings. A VBT can be larger than the allocated space of 6 KB inside the OpRegion. For larger VBTs, Intel added two fields to the OpRegion to report the VBT address and the VBT size. Make bhyve aware of those fields and put the VBT into the guest memory too. Unfortunately, Intel forgot to consider virtualization when defining OpRegion v2.0. OpRegion v2.0 uses an absolute address for pointing to the VBT. This address is useless in a guest environment. It's possible to patch that. However, it requires some more work and we can't test it because we have no test device with this combination. Therefore, we don't want to do that yet until we have a use case. Fortunately, Intel noticed the issue and from v2.1 onwards, the VBT address is a relative address. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D45337
* bhyve x86: when accessing non-backed gpa, emulate hwKonstantin Belousov2025-05-152-1/+83
| | | | | | | | | | which reads all bits one, and ignores writes. PR: 286467 Reviewed by: markj (previous version) Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D50116
* bhyve: make code to handle non-backed memory accesses MDKonstantin Belousov2025-05-151-0/+1
| | | | | | | | PR: 286467 Reviewed by: markj (previous version) Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D50116
* bhyve: Suppress unimplemented MSR related warningsbrendabrandy2025-03-242-4/+11
| | | | | | | | | | | When using bhyve on x86, rdmsr and wrmsr can emit many warnings when dealing with unimplemented MSRs. An option x86.verbosemsr is created to control these warnings. By default, the MSR related warnings are suppressed to avoid spamming the console. Sponsored by: Netflix Reviewed by: imp, jhb Pull Request: https://github.com/freebsd/freebsd-src/pull/1611
* bhyve: merge adjacent E820 entriesCorvin Köhne2024-10-221-0/+28
| | | | | | | | | | | | | | | EDKII can allocate adjacent E820 entries only if they are at a page boundary. For some unknown and probably strange reasons, Intel puts it's OpRegion at an offset of 0x18 bytes. If the VBT lays directly behind the OpRegion, we're going to try allocating two adjacent E820 sharing the same page. This causes EDKII to do not properly allocate those entries. A Linux guest then isn't able to map the VBT and those fails to find it. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D45336
* bhyve: Make boot ROM handling more consistentMark Johnston2024-08-195-22/+24
| | | | | | | | | | | | - 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
* bhyve: remove empty E820 entriesCorvin Köhne2024-08-091-1/+13
| | | | | | | | | | | When reserving a block with the same size of a RAM segement, we can end up with an empty RAM segmenet. Avoid that by removing this empty segment from the E820 table. Reviewed by: jhb, markj (older version) MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D45480
* bhyve: verify OpRegion sizeCorvin Köhne2024-06-041-0/+7
| | | | | | | | | | | | If the OpRegion size doesn't match the size of our igd_opregion struct, it's using a different layout than we're expecting. To avoid strange issues, we should exit hard. If we see any devices in the field with a different OpRegion size, we can analyse it and fix it accordingly. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D45335
* bhyve: use correct size to map the OpRegionCorvin Köhne2024-06-041-2/+2
| | | | | | | | | | We're already converting the size reported by the OpRegion header from kilobytes to bytes. We don't have to do that twice when mapping the OpRegion. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D45334
* bhyve: correctly remove a memory mappingPierre Pronchery2024-05-291-1/+1
| | | | | | | | | | | | | In a normal code path while setting up GPU passthrough, the size parameter to munmap() is wrong and its operation not checked for errors, therefore leaking resources. Reported by: Coverity Scan CID: 1519830 Sponsored by: The FreeBSD Foundation Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1262
* bhyve: avoid resource leak in error pathPierre Pronchery2024-05-171-0/+2
| | | | | | | | | | | | In e820_finalize(), the e820_fwcfg_item variable, containing the etc/e820 file (for the e820 table from the BIOS) is not free()'d when it could not be added to the QEMU firmware configuration device (fw_cfg). Reported by: Coverity Scan CID: 1522761 Reviewed by: corvink, jhb Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D45223
* bhyve.8: Remove mention of the -A flagMark Johnston2024-04-241-2/+1
| | | | | | | | | | It is a no-op on amd64 now and is not implemented on arm64, so let's remove mention of it altogether so as to reduce confusion for arm64 users. Reviewed by: corvink, jhb Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D44737
* usr.sbin: Remove repeated wordsElyes Haouas2024-04-111-1/+1
| | | | | | Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/887
* bhyve: Support legacy PCI interrupts on arm64Jessica Clarke2024-04-104-22/+52
| | | | | | | | | | | | | 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
* bhyve: Push option parsing down into bhyverun_machdep.cMark Johnston2024-04-101-0/+181
| | | | | | | | | | | | | | | After a couple of attempts I think this is the cleanest approach despite the expense of some code duplication. Quite a few of the single-letter bhyve options are x86-specific. I think that going forward we should strongly discourage the addition of new options and instead configure guests using the more general configuration file syntax. Reviewed by: corvink, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D41753
* bhyve: Do not compile PCI passthrough support on arm64Mark Johnston2024-04-101-0/+1
| | | | | | | | | | | | | | Some required kernel functionality is not yet implemented. For now this means that one cannot specify host PCI register values, but that functionality is only used by amd64-specific device models for now. Note that this limitation is rather artificial; it arises only because pci_host_read_config() lives in pci_passthru.c. Reviewed by: corvink, andrew, jhb MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D41738
* bhyve: Move device model-independent UART code into a separate fileMark Johnston2024-03-211-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* bhyve: refactor gdbstub to enable single-stepping on AMD CPUsBojan Novković2023-12-121-0/+15
| | | | | | | | | This patch refactors the existing Intel-specific single-stepping mechanism in bhyve's GDB stub to work with both AMD and Intel CPUs. Reviewed by: jhb Sponsored by: Google, Inc. (GSoC 2022) Differential Revision: https://reviews.freebsd.org/D42298
* usr.sbin: Automated cleanup of cdefs and other formattingWarner Losh2023-11-2717-18/+2
| | | | | | | | | | | | | | | | Apply the following automated changes to try to eliminate no-longer-needed sys/cdefs.h includes as well as now-empty blank lines in a row. Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/ Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/ Remove /\n+#if.*\n#endif.*\n+/ Remove /^#if.*\n#endif.*\n/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/ Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/ Sponsored by: Netflix
* bhyve: ps2 implement command 0xf6Warner Losh2023-10-311-0/+5
| | | | | | | | | | | | | | | | | Implement PS2 Keyboard command 0xf6, which is "SET DEFAULTS". This is the same as 0xf5 (DISABLE KEYBOARD), but without disabling the keyboard (since that resets all the defaults as a side effect). Normally, we clear the fifo when we re-enable the keyboard. However, since this leaves the keyboard enabled, clear the fifo as part of this command and send an ack. Linux's keyboard driver sends this command on reboot. Other commands enable / reset the kebyoard, so it doesn't matter too much this isn't implemented for booting, eg ubuntu. Sponsored by: Netflix Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D42384
* bhyve: Replace many fprintf(stderr, ...) calls with EPRINTLNJohn Baldwin2023-10-163-29/+30
| | | | | | | | | | | | 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
* bhyve: Some fwctl simplifications.John Baldwin2023-10-131-12/+9
| | | | | | | | | | | - Collapse IDENT_SEND/IDENT_WAIT states down to a single state. - Remove unused 'len' argument to op_data callback. The value passed in (total amount of remaining data to receive) didn't seem very useful and no op_data implementations used it. Reviewed by: corvink, markj Differential Revision: https://reviews.freebsd.org/D41286
* bhyve: Move the vm_inject_fault() implementation to vmexit.cMark Johnston2023-10-041-0/+13
| | | | | | | | | | This function isn't generic and has a different signature on arm64. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40991
* bhyve: Move most early initialization into an MD routineMark Johnston2023-10-042-3/+66
| | | | | | | | | | | | | | Prior to initializing PCI devices, main() calls a number of initialization routines, many of which are amd64-specific. Move this list of calls to bhyverun_machdep.c. Similarly, add an MD function to handle late initialization. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40989
* bhyve: Move vcpu initialization into a MD source fileMark Johnston2023-10-041-0/+125
| | | | | | | | | | | | | | | | | - 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
* bhyve: Make gdb support optionalMark Johnston2023-10-041-0/+2
| | | | | | | | | | | | | | | 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
* bhyve: Make most I/O port handling specific to amd64Mark Johnston2023-10-043-0/+375
| | | | | | | | | | | | | | - The qemu_fwcfg interface, as implemented, is I/O port-based, but QEMU implements an MMIO interface that we'll eventually want to port for arm64. - Retain support for I/O space PCI BARs, simply treat them like MMIO BARs for most purposes, similar to what the arm64 kernel does. Such BARs are created by virtio devices. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40741
* bhyve: Conditionally compile framebuffer-related codeMark Johnston2023-10-043-0/+1496
| | | | | | | | | | | | | The arm64 port does not implement VGA, so move the device model sources. Compile framebuffer code only on amd64 for now, but do not move the sources, as we ought to be able to add support later. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40740
* bhyve: Move legacy PCI interrupt handling under amd64/Mark Johnston2023-10-047-0/+1221
| | | | | | | | | | | | | | | | | | | | Specifically, move IO-APIC, LPC and PIRQ routing code under amd64/. Use ifdefs to conditionally compile related code in other files. In particular, legacy PCI interrupt handling is now compiled only on amd64. This is not too invasive, but suggestions for a more modular approach would be appreciated. I am not sure why qemu fwcfg handling is tied to LPC, and I suspect it should be decoupled. In this commit I just apply an ifdef hammer, but we will eventually want fwcfg on arm64 as well. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40739
* bhyve: Compile some device models only on amd64Mark Johnston2023-10-041-0/+6
| | | | | | | | | | | | | | These models register legacy PCI interrupts, which won't be supported in the arm64 port. In principle it should be possible to make these models work on arm64 with a bit of effort, so don't move the sources to the amd64 subdirectory. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40738
* bhyve: Move AP startup code to amd64/Mark Johnston2023-10-043-0/+120
| | | | | | | | | | This code is only invoked via MD vmexit handlers. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40737
* bhyve: Move the gvt-d driver to amd64/Mark Johnston2023-10-043-0/+491
| | | | | | | | | It is amd64-only. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40736
* bhyve: Move power management code to amd64/Mark Johnston2023-10-042-0/+378
| | | | | | | | | | This implements various x86-specific interfaces. No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40735
* bhyve: Move the RTC driver to amd64/Mark Johnston2023-10-043-0/+163
| | | | | | | | | No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40734
* bhyve: Move MSR emulation into amd64/Mark Johnston2023-10-043-1/+280
| | | | | | | | | No functional change intended. Reviewed by: corvink, jhb MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40733
* bhyve: Split vmexit handling into a separate fileMark Johnston2023-10-041-0/+493
| | | | | | | | | | | | | | | | 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
* bhyve: Move kernemu to amd64/Mark Johnston2023-10-043-1/+129
| | | | | | | | | | | | This code handles instruction emulation for accesses to various amd64-specific MMIO regions. No functional change intended. Reviewed by: corvink, jhb, emaste MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40554
* bhyve: Move more amd64-specific code under amd64/Mark Johnston2023-10-045-0/+948
| | | | | | | | | | | | | | | mptable and the e820 are both rather amd64-specific and can be moved easily. In the case of e820, move the registration with qemu_fwcfg into e820.c, as it simplifies bhyverun.c a bit and I can't see any downsides. No functional change intended. Reviewed by: corvink, jhb, emaste MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40552
* bhyve: Move some more amd64-specific drivers to their own subdirMark Johnston2023-10-048-0/+1775
| | | | | | | | | No functional change intended. Reviewed by: corvink, jhb, emaste MFC after: 1 week Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D40551
generated by cgit v1.3 (git 2.53.0) at 2026-05-27 00:55:08 +0000