vmm: Start using exterror

For now, just describe the error where an unprivileged user attempts to
run a VM without DESTROY_ON_CLOSE semantics, i.e., monitor mode.

Reviewed by: bnovkov
MFC after: 2

vmm: Start using exterror

For now, just describe the error where an unprivileged user attempts to
run a VM without DESTROY_ON_CLOSE semantics, i.e., monitor mode.

Reviewed by: bnovkov
MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54743

show more ...

vmm: Enable unprivileged bhyve

- Add the vmm group.
- Let /dev/vmmctl belong to the vmm group by default, and give group
write permissions.
- When creating a VM's device files, make them owned by

vmm: Enable unprivileged bhyve

- Add the vmm group.
- Let /dev/vmmctl belong to the vmm group by default, and give group
write permissions.
- When creating a VM's device files, make them owned by the creating
process' effective UID.

Reviewed by: bnovkov
MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54741

show more ...

vmm: Add privilege checks to vmmctl operations

In preparation for supporting creation of VMs by unprivileged users, add
some restrictions:
- Disallow creation of non-transient VMs by unprivileged us

vmm: Add privilege checks to vmmctl operations

In preparation for supporting creation of VMs by unprivileged users, add
some restrictions:
- Disallow creation of non-transient VMs by unprivileged users. That
is, if an unprivileged user creates a VM, the VM must be destroyed
automatically once the last fd referencing it is gone.
- Disallow destroying VMs created by a different user, unless the caller
has the PRIV_VMM_DESTROY privilege.

Reviewed by: bnovkov
MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54740

show more ...

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 ...

vmm: Remove an unneeded NULL pointer check

sc->vm is unconditionally dereferenced earlier in this function. No
functional change intended.

Reviewed by: bnovkov
MFC after: 1 week
Differential Revis

vmm: Remove an unneeded NULL pointer check

sc->vm is unconditionally dereferenced earlier in this function. No
functional change intended.

Reviewed by: bnovkov
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55069

show more ...

vmm: Fix a resource leak in an error path

vmmdev_create() increments the VM count as its last step and calls
vmmdev_destroy() if it fails. However, vmmdev_destroy() unconditionally
decrements the c

vmm: Fix a resource leak in an error path

vmmdev_create() increments the VM count as its last step and calls
vmmdev_destroy() if it fails. However, vmmdev_destroy() unconditionally
decrements the count.

Correct this bug by reordering operations.

Fixes: 1092ec8b3375 ("kern: Introduce RLIMIT_VMM")
Reviewed by: bnovkov
Differential Revision: https://reviews.freebsd.org/D55068

show more ...

vmm: Avoid clobbering errors from vmm_modinit()

Reported by: novel
Reviewed by: bnovkov
Fixes: e758074458df ("vmm: Move the module load handler to vmm_dev.c")
Differential Revision: https://reviews

vmm: Avoid clobbering errors from vmm_modinit()

Reported by: novel
Reviewed by: bnovkov
Fixes: e758074458df ("vmm: Move the module load handler to vmm_dev.c")
Differential Revision: https://reviews.freebsd.org/D54750

show more ...

vmm: Deduplicate VM and vCPU state management code

Now that the machine-independent fields of struct vm and struct vcpu are
available in a header, we can move lots of duplicated code into
sys/dev/vm

vmm: Deduplicate VM and vCPU state management code

Now that the machine-independent fields of struct vm and struct vcpu are
available in a header, we can move lots of duplicated code into
sys/dev/vmm/vmm_vm.c. This change does exactly that.

No functional change intended.

MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D53585

show more ...

vmm: Consolidate vm and vcpu definitions

There is quite a lot of duplication of code between amd64, arm64 and
riscv with respect to VM and vCPU state management. This is a bit
tricky to resolve sin

vmm: Consolidate vm and vcpu definitions

There is quite a lot of duplication of code between amd64, arm64 and
riscv with respect to VM and vCPU state management. This is a bit
tricky to resolve since struct vm and struct vcpu are private to vmm.c
and both structures contain a mix of machine-dependent and
machine-independent fields.

To allow deduplication without also introducing a lot of churn, follow
the approach of struct pcpu and 1) lift the definitions of those
structures into a new header, sys/dev/vmm/vmm_vm.h, and 2) define
machine-dependent macros, VMM_VM_MD_FIELDS and VMM_VCPU_MD_FIELDS which
lay out the machine-dependent fields.

One disadvantage of this approach is that the two structures are no
longer private to vmm.c, but I think this is acceptable.

No functional change intended. A follow-up change will move a good deal
of machine/vmm/vmm.c into sys/dev/vmm/vmm_vm.c.

MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D53584

show more ...

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 ...

kern: Introduce RLIMIT_VMM

This change introduces a new per-UID limit for controlling the
number of vmm instances, in anticipation of unprivileged bhyve.
This allows ut to limit the amount of kernel

kern: Introduce RLIMIT_VMM

This change introduces a new per-UID limit for controlling the
number of vmm instances, in anticipation of unprivileged bhyve.
This allows ut to limit the amount of kernel memory allocated
by the vmm driver and prevent potential memory exhaustion attacks.

Differential Revision: https://reviews.freebsd.org/D53728
Reviewed by: markj, olce, corvink
MFC after: 3 months
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.

show more ...

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 ...

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 ...

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 ...

vmm: Simplify the VM_ALLOC_MEMSEG ioctl a bit

We can free the mask earlier, simplifying some error paths. No
functional change intended.

Reviewed by: corvink, jhb, emaste
Sponsored by: The FreeBSD

vmm: Simplify the VM_ALLOC_MEMSEG ioctl a bit

We can free the mask earlier, simplifying some error paths. No
functional change intended.

Reviewed by: corvink, jhb, emaste
Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D53418

show more ...

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 ...

vmm: Improve register get/set handling a bit

On non-amd64 platforms, check for negative register indices. This isn't
required today since we match against individual register indices, but
we might

vmm: Improve register get/set handling a bit

On non-amd64 platforms, check for negative register indices. This isn't
required today since we match against individual register indices, but
we might as well check it. On amd64, add a comment explaining why we
permit negative register indices.

Use mallocarray() for allocating register arrays in the ioctl layer.

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/D53143

show more ...

vmm: Fix a deadlock between vm_smp_rendezvous() and vcpu_lock_all()

vm_smp_rendezvous() invokes a callback on all vCPUs, blocking the
initiator until all vCPUs have responded. vcpu_lock_all() block

vmm: Fix a deadlock between vm_smp_rendezvous() and vcpu_lock_all()

vm_smp_rendezvous() invokes a callback on all vCPUs, blocking the
initiator until all vCPUs have responded. vcpu_lock_all() blocks each
vCPU by waiting for it to go idle and setting the vCPU state to frozen.
These two operations can deadlock on each other, particularly when
booting a Windows guest, when vcpu_lock_all() blocks waiting for a
rendezvous initiator, and the initiator is blocked waiting for the vCPU
thread which called vcpu_lock_all() to invoke the rendezvous callback.

Implement vcpu_lock_all() in a way that avoids deadlocks with
vm_smp_rendezvous(). In particular, when traversing vCPUs, invoke the
rendezvous callback on the vCPU's behalf to help the initiator finish.
We can only safely do so when the vCPU is IDLE or we have already locked
it, otherwise we may be racing with the target vCPU thread. Thus:
- Use an exclusive lock to serialize vcpu_lock_all() callers, which lets
us lock vCPUs out of order without fear of deadlock with parallel
vcpu_lock_all() callers.
- If a rendezvous is pending, lock all idle vCPUs and invoke the
callback on their behalf. If the vcpu_lock_all() caller is itself a
vCPU thread, this will handle that thread.
- Block waiting for all non-idle vCPUs to idle, or until one of them
initiates a rendezvous, in which case we go back and invoke callbacks
on behalf of already-locked vCPUs.

Note that on !amd64 no changes are needed since there is no rendezvous
mechanism, so there is a separate vcpu_set_state_all() for them based on
the previous vcpu_lock_all(). These will be merged together once vcpu
state handling is consolidated into sys/dev/vmm.

Reviewed by: corvink (previous version)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D52968

show more ...

vmm: Suspend the VM before destroying it

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

vmm: Suspend the VM before destroying it

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

show more ...

vmm: Add support for guest NUMA emulation

This change adds the necessary kernelspace bits required for
supporting NUMA domains in bhyve VMs.

The layout of system memory segments and how they're cre

vmm: Add support for guest NUMA emulation

This change adds the necessary kernelspace bits required for
supporting NUMA domains in bhyve VMs.

The layout of system memory segments and how they're created has
been reworked. Each guest NUMA domain will now have its own memory
segment. Furthermore, this change allows users to tweak the domain's
backing vm_object domainset(9) policy.

Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44565

show more ...

vmm: Clean up legacy create/destroy interface

Add sysctl descriptions, and remove surprising default text.

PR: 288437
Reviewed by: jhb, markj
Sponsored by: The FreeBSD Foundation
Differential Revi

vmm: Clean up legacy create/destroy interface

Add sysctl descriptions, and remove surprising default text.

PR: 288437
Reviewed by: jhb, markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51533

show more ...

vmm: Add a missing entry to the ioctl table

Reported by: acm
Fixes: b9ef152bec6c ("vmm: Merge vmm_dev.c")

vmm: Consolidate code which manages guest memory regions

On all three platforms supported by vmm, we have mostly duplicated code
to manage guest physical memory regions. Deduplicate much of this co

vmm: Consolidate code which manages guest memory regions

On all three platforms supported by vmm, we have mostly duplicated code
to manage guest physical memory regions. Deduplicate much of this code
and move it into sys/dev/vmm/vmm_mem.c.

To avoid exporting struct vm outside of machdep vmm.c, add a new
struct vm_mem to contain the memory segment descriptors, and add a
vm_mem() accessor, akin to vm_vmspace(). This way vmm_mem.c can
implement its routines without needing to see the layout of struct vm.

The handling of the per-VM vmspace is also duplicated but will be moved
to vmm_mem.c in a follow-up patch.

On amd64, move the ppt_is_mmio() check out of vm_mem_allocated() to keep
the code MI, as PPT is only implemented on amd64. There are only a
couple of callers, so this is not unreasonable.

No functional change intended.

Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D48270

show more ...

vmm: Fix error handling in vmm_handler()

In commit a97f683fe3c4 I didn't add code to remove the vmmctl device
when vmm.ko is unloaded, so it would persist and prevent vmm.ko from
being re-loaded.

E

vmm: Fix error handling in vmm_handler()

In commit a97f683fe3c4 I didn't add code to remove the vmmctl device
when vmm.ko is unloaded, so it would persist and prevent vmm.ko from
being re-loaded.

Extend vmmdev_cleanup() to destroy the vmmctl cdev. Also call
vmmdev_cleanup() if vmm_init() fails.

Reviewed by: corvink, andrew
Fixes: a97f683fe3c4 ("vmm: Add a device file interface for creating and destroying VMs")
Differential Revision: https://reviews.freebsd.org/D48269

show more ...

vmm: Initialize error in vmmdev_rw

CID: 1568045
Reported by: Coverity Scan
Reviewed by: markj
Fixes: 4008758105a6 vmm: Validate credentials when opening a vmmdev
Differential Revision: https://rev

vmm: Initialize error in vmmdev_rw

CID: 1568045
Reported by: Coverity Scan
Reviewed by: markj
Fixes: 4008758105a6 vmm: Validate credentials when opening a vmmdev
Differential Revision: https://reviews.freebsd.org/D48073

show more ...