| #
c7135403
|
| 16-Feb-2026 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Allow the use of PCI passthrough in a jail
After commit e11768e94787 ("vmm: Add PRIV_DRIVER checks for passthru ioctls"), it is not possible to use PCI passthru from jails, as PRIV_DRIVER is no
vmm: Allow the use of PCI passthrough in a jail
After commit e11768e94787 ("vmm: Add PRIV_DRIVER checks for passthru ioctls"), it is not possible to use PCI passthru from jails, as PRIV_DRIVER is not granted to jails. Apparently some users expect this to work, understanding that jailing bhyve provides little security benefit in this configuration.
I believe we should disable ppt access in jails even when allow.vmm is configured. To provide an escape hatch for users, add a new allow.vmm_ppt jail configuration knob, and check it when handling ppt ioctls in jails. Also add a new PRIV_VMM_PPTDEV to replace the use of PRIV_DRIVER.
PR: 292750 Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55066
show more ...
|
| #
bd16bac2
|
| 06-Nov-2025 |
Bojan Novković <bnovkov@FreeBSD.org> |
vmm: Add ability to destroy VMs on close
This change adds the ability to tie a virtual machine's lifecycle to a /dev/vmmctl file descriptor. A user can request `vmmctl` to destroy a virtual machine
vmm: Add ability to destroy VMs on close
This change adds the ability to tie a virtual machine's lifecycle to a /dev/vmmctl file descriptor. A user can request `vmmctl` to destroy a virtual machine on close using the `VMMCTL_CREATE_DESTROY_ON_CLOSE` flag when creating the virtual machine. `vmmctl` tracks such virtual machines in per-descriptor lists.
Differential Revision: https://reviews.freebsd.org/D53729 Reviewed by: markj Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. MFC after: 3 months
show more ...
|
| #
c46e5dc6
|
| 04-Nov-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Move vm_maxcpu handling into MI code
No functional change intended.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision
vmm: Move vm_maxcpu handling into MI code
No functional change intended.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53477
show more ...
|
| #
7377c87e
|
| 04-Nov-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Consolidate VM name length checking
vm_create() is only called from one place. Rather than having similar checks everywhere, move them to vmmdev_create().
We can safely assume that the name i
vmm: Consolidate VM name length checking
vm_create() is only called from one place. Rather than having similar checks everywhere, move them to vmmdev_create().
We can safely assume that the name is nul-terminated, the vmmctl ioctl handler and the legacy sysctl handler ensure this. So, don't bother with strnlen().
Finally, make sure that the name buffers are the same size on all platforms. VM_MAX_NAMELEN is supposed to be the maximum, not including the nul terminator.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53422
show more ...
|
| #
e7580744
|
| 04-Nov-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Move the module load handler to vmm_dev.c
Move the vmm_initialized check out of vm_create() and into the legacy sysctl handler. If vmm_initialized is false, /dev/vmmctl will not be available a
vmm: Move the module load handler to vmm_dev.c
Move the vmm_initialized check out of vm_create() and into the legacy sysctl handler. If vmm_initialized is false, /dev/vmmctl will not be available and so cannot be used to create VMs.
Introduce new MD vmm_modinit() and vmm_modcleanup() routines which handle MD (de)initialization.
No functional change intended.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53421
show more ...
|
| #
e11768e9
|
| 21-Oct-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Add PRIV_DRIVER checks for passthru ioctls
In preparation for allowing non-root users to create and access bhyve VMs, add privilege checks for ioctls which operate on passthru devices.
Reviewe
vmm: Add PRIV_DRIVER checks for passthru ioctls
In preparation for allowing non-root users to create and access bhyve VMs, add privilege checks for ioctls which operate on passthru devices.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53144
show more ...
|
| #
a97f683f
|
| 05-Nov-2024 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Add a device file interface for creating and destroying VMs
This supersedes the sysctl interface, which has the limitations of being root-only and not supporting automatic resource destruction,
vmm: Add a device file interface for creating and destroying VMs
This supersedes the sysctl interface, which has the limitations of being root-only and not supporting automatic resource destruction, i.e., we cannot easily destroy VMs automatically when bhyve terminates.
For now, two ioctls are implemented VMMCTL_VM_CREATE and VMMCTL_VM_DESTROY. Eventually I would like to support tying a VM's lifetime to that of the descriptor, so that it is automatically destroyed when the descriptor is closed. However, this will require some work in bhyve: when the guest wants to reboot, bhyve exits with a status that indicates that it is to be restarted. This is incompatible with the idea of tying a VM's lifetime to that of a descriptor, since we want to avoid creating and destroying a VM across each reboot (as this involves freeing all of the guest memory, among other things). One possible design would be to decompose bhyve into two processes, a parent which handles reboots, and a child which runs in capability mode and handles guest execution.
In any case, this gets us closer to addressing the shortcomings mentioned above.
Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D47028
show more ...
|
| #
b9ef152b
|
| 26-Aug-2024 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Merge vmm_dev.c
This file contains the vmm device file implementation. Most of this code is not machine-dependent and so shouldn't be duplicated this way. Move most of it into a generic dev/vm
vmm: Merge vmm_dev.c
This file contains the vmm device file implementation. Most of this code is not machine-dependent and so shouldn't be duplicated this way. Move most of it into a generic dev/vmm/vmm_dev.c. This will make it easier to introduce a cdev-based interface for VM creation, which in turn makes it possible to implement support for running bhyve as an unprivileged user.
Machine-dependent ioctls continue to be handled in machine-dependent code. To make the split a bit easier to handle, introduce a pair of tables which define MI and MD ioctls. Each table entry can set flags which determine which locks need to be held in order to execute the handler. vmmdev_ioctl() now looks up the ioctl in one of the tables, acquires locks and either handles the ioctl directly or calls vmmdev_machdep_ioctl() to handle it.
No functional change intended. There is a lot of churn in this change but the underlying logic in the ioctl handlers is the same. For now, vmm_dev.h is still mostly separate, even though some parts could be merged in principle. This would involve changing include paths for userspace, though.
Reviewed by: corvink, jhb Differential Revision: https://reviews.freebsd.org/D46431
show more ...
|
| #
bd16bac2
|
| 06-Nov-2025 |
Bojan Novković <bnovkov@FreeBSD.org> |
vmm: Add ability to destroy VMs on close
This change adds the ability to tie a virtual machine's lifecycle to a /dev/vmmctl file descriptor. A user can request `vmmctl` to destroy a virtual machine
vmm: Add ability to destroy VMs on close
This change adds the ability to tie a virtual machine's lifecycle to a /dev/vmmctl file descriptor. A user can request `vmmctl` to destroy a virtual machine on close using the `VMMCTL_CREATE_DESTROY_ON_CLOSE` flag when creating the virtual machine. `vmmctl` tracks such virtual machines in per-descriptor lists.
Differential Revision: https://reviews.freebsd.org/D53729 Reviewed by: markj Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. MFC after: 3 months
show more ...
|
| #
c46e5dc6
|
| 04-Nov-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Move vm_maxcpu handling into MI code
No functional change intended.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision
vmm: Move vm_maxcpu handling into MI code
No functional change intended.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53477
show more ...
|
| #
7377c87e
|
| 04-Nov-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Consolidate VM name length checking
vm_create() is only called from one place. Rather than having similar checks everywhere, move them to vmmdev_create().
We can safely assume that the name i
vmm: Consolidate VM name length checking
vm_create() is only called from one place. Rather than having similar checks everywhere, move them to vmmdev_create().
We can safely assume that the name is nul-terminated, the vmmctl ioctl handler and the legacy sysctl handler ensure this. So, don't bother with strnlen().
Finally, make sure that the name buffers are the same size on all platforms. VM_MAX_NAMELEN is supposed to be the maximum, not including the nul terminator.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53422
show more ...
|
| #
e7580744
|
| 04-Nov-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Move the module load handler to vmm_dev.c
Move the vmm_initialized check out of vm_create() and into the legacy sysctl handler. If vmm_initialized is false, /dev/vmmctl will not be available a
vmm: Move the module load handler to vmm_dev.c
Move the vmm_initialized check out of vm_create() and into the legacy sysctl handler. If vmm_initialized is false, /dev/vmmctl will not be available and so cannot be used to create VMs.
Introduce new MD vmm_modinit() and vmm_modcleanup() routines which handle MD (de)initialization.
No functional change intended.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53421
show more ...
|
| #
e11768e9
|
| 21-Oct-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Add PRIV_DRIVER checks for passthru ioctls
In preparation for allowing non-root users to create and access bhyve VMs, add privilege checks for ioctls which operate on passthru devices.
Reviewe
vmm: Add PRIV_DRIVER checks for passthru ioctls
In preparation for allowing non-root users to create and access bhyve VMs, add privilege checks for ioctls which operate on passthru devices.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53144
show more ...
|
| #
a97f683f
|
| 05-Nov-2024 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Add a device file interface for creating and destroying VMs
This supersedes the sysctl interface, which has the limitations of being root-only and not supporting automatic resource destruction,
vmm: Add a device file interface for creating and destroying VMs
This supersedes the sysctl interface, which has the limitations of being root-only and not supporting automatic resource destruction, i.e., we cannot easily destroy VMs automatically when bhyve terminates.
For now, two ioctls are implemented VMMCTL_VM_CREATE and VMMCTL_VM_DESTROY. Eventually I would like to support tying a VM's lifetime to that of the descriptor, so that it is automatically destroyed when the descriptor is closed. However, this will require some work in bhyve: when the guest wants to reboot, bhyve exits with a status that indicates that it is to be restarted. This is incompatible with the idea of tying a VM's lifetime to that of a descriptor, since we want to avoid creating and destroying a VM across each reboot (as this involves freeing all of the guest memory, among other things). One possible design would be to decompose bhyve into two processes, a parent which handles reboots, and a child which runs in capability mode and handles guest execution.
In any case, this gets us closer to addressing the shortcomings mentioned above.
Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D47028
show more ...
|
| #
b9ef152b
|
| 26-Aug-2024 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Merge vmm_dev.c
This file contains the vmm device file implementation. Most of this code is not machine-dependent and so shouldn't be duplicated this way. Move most of it into a generic dev/vm
vmm: Merge vmm_dev.c
This file contains the vmm device file implementation. Most of this code is not machine-dependent and so shouldn't be duplicated this way. Move most of it into a generic dev/vmm/vmm_dev.c. This will make it easier to introduce a cdev-based interface for VM creation, which in turn makes it possible to implement support for running bhyve as an unprivileged user.
Machine-dependent ioctls continue to be handled in machine-dependent code. To make the split a bit easier to handle, introduce a pair of tables which define MI and MD ioctls. Each table entry can set flags which determine which locks need to be held in order to execute the handler. vmmdev_ioctl() now looks up the ioctl in one of the tables, acquires locks and either handles the ioctl directly or calls vmmdev_machdep_ioctl() to handle it.
No functional change intended. There is a lot of churn in this change but the underlying logic in the ioctl handlers is the same. For now, vmm_dev.h is still mostly separate, even though some parts could be merged in principle. This would involve changing include paths for userspace, though.
Reviewed by: corvink, jhb Differential Revision: https://reviews.freebsd.org/D46431
show more ...
|
| #
bd16bac2
|
| 06-Nov-2025 |
Bojan Novković <bnovkov@FreeBSD.org> |
vmm: Add ability to destroy VMs on close
This change adds the ability to tie a virtual machine's lifecycle to a /dev/vmmctl file descriptor. A user can request `vmmctl` to destroy a virtual machine
vmm: Add ability to destroy VMs on close
This change adds the ability to tie a virtual machine's lifecycle to a /dev/vmmctl file descriptor. A user can request `vmmctl` to destroy a virtual machine on close using the `VMMCTL_CREATE_DESTROY_ON_CLOSE` flag when creating the virtual machine. `vmmctl` tracks such virtual machines in per-descriptor lists.
Differential Revision: https://reviews.freebsd.org/D53729 Reviewed by: markj Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. MFC after: 3 months
show more ...
|
| #
c46e5dc6
|
| 04-Nov-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Move vm_maxcpu handling into MI code
No functional change intended.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision
vmm: Move vm_maxcpu handling into MI code
No functional change intended.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53477
show more ...
|
| #
7377c87e
|
| 04-Nov-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Consolidate VM name length checking
vm_create() is only called from one place. Rather than having similar checks everywhere, move them to vmmdev_create().
We can safely assume that the name i
vmm: Consolidate VM name length checking
vm_create() is only called from one place. Rather than having similar checks everywhere, move them to vmmdev_create().
We can safely assume that the name is nul-terminated, the vmmctl ioctl handler and the legacy sysctl handler ensure this. So, don't bother with strnlen().
Finally, make sure that the name buffers are the same size on all platforms. VM_MAX_NAMELEN is supposed to be the maximum, not including the nul terminator.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53422
show more ...
|
| #
e7580744
|
| 04-Nov-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Move the module load handler to vmm_dev.c
Move the vmm_initialized check out of vm_create() and into the legacy sysctl handler. If vmm_initialized is false, /dev/vmmctl will not be available a
vmm: Move the module load handler to vmm_dev.c
Move the vmm_initialized check out of vm_create() and into the legacy sysctl handler. If vmm_initialized is false, /dev/vmmctl will not be available and so cannot be used to create VMs.
Introduce new MD vmm_modinit() and vmm_modcleanup() routines which handle MD (de)initialization.
No functional change intended.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53421
show more ...
|
| #
e11768e9
|
| 21-Oct-2025 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Add PRIV_DRIVER checks for passthru ioctls
In preparation for allowing non-root users to create and access bhyve VMs, add privilege checks for ioctls which operate on passthru devices.
Reviewe
vmm: Add PRIV_DRIVER checks for passthru ioctls
In preparation for allowing non-root users to create and access bhyve VMs, add privilege checks for ioctls which operate on passthru devices.
Reviewed by: corvink MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D53144
show more ...
|
| #
a97f683f
|
| 05-Nov-2024 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Add a device file interface for creating and destroying VMs
This supersedes the sysctl interface, which has the limitations of being root-only and not supporting automatic resource destruction,
vmm: Add a device file interface for creating and destroying VMs
This supersedes the sysctl interface, which has the limitations of being root-only and not supporting automatic resource destruction, i.e., we cannot easily destroy VMs automatically when bhyve terminates.
For now, two ioctls are implemented VMMCTL_VM_CREATE and VMMCTL_VM_DESTROY. Eventually I would like to support tying a VM's lifetime to that of the descriptor, so that it is automatically destroyed when the descriptor is closed. However, this will require some work in bhyve: when the guest wants to reboot, bhyve exits with a status that indicates that it is to be restarted. This is incompatible with the idea of tying a VM's lifetime to that of a descriptor, since we want to avoid creating and destroying a VM across each reboot (as this involves freeing all of the guest memory, among other things). One possible design would be to decompose bhyve into two processes, a parent which handles reboots, and a child which runs in capability mode and handles guest execution.
In any case, this gets us closer to addressing the shortcomings mentioned above.
Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D47028
show more ...
|
| #
b9ef152b
|
| 26-Aug-2024 |
Mark Johnston <markj@FreeBSD.org> |
vmm: Merge vmm_dev.c
This file contains the vmm device file implementation. Most of this code is not machine-dependent and so shouldn't be duplicated this way. Move most of it into a generic dev/vm
vmm: Merge vmm_dev.c
This file contains the vmm device file implementation. Most of this code is not machine-dependent and so shouldn't be duplicated this way. Move most of it into a generic dev/vmm/vmm_dev.c. This will make it easier to introduce a cdev-based interface for VM creation, which in turn makes it possible to implement support for running bhyve as an unprivileged user.
Machine-dependent ioctls continue to be handled in machine-dependent code. To make the split a bit easier to handle, introduce a pair of tables which define MI and MD ioctls. Each table entry can set flags which determine which locks need to be held in order to execute the handler. vmmdev_ioctl() now looks up the ioctl in one of the tables, acquires locks and either handles the ioctl directly or calls vmmdev_machdep_ioctl() to handle it.
No functional change intended. There is a lot of churn in this change but the underlying logic in the ioctl handlers is the same. For now, vmm_dev.h is still mostly separate, even though some parts could be merged in principle. This would involve changing include paths for userspace, though.
Reviewed by: corvink, jhb Differential Revision: https://reviews.freebsd.org/D46431
show more ...
|