History log of /src/sys/dev/vmm/vmm_dev.h (Results 1 – 22 of 22)
Revision Date Author Comments
# 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 ...