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

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

vmm: Remove more of vmmdev_open()

The softc pointer is now unused, just remove it.

Reported by: se
Fixes: 66fc442421f8 ("vmm: Remove an incorrect credential check in vmmdev_open()")

vmm: Remove an incorrect credential check in vmmdev_open()

Checking pointer equality here is too strict and can lead to incorrect
errors, as credentials are frequently copied to avoid reference coun

vmm: Remove an incorrect credential check in vmmdev_open()

Checking pointer equality here is too strict and can lead to incorrect
errors, as credentials are frequently copied to avoid reference counting
overhead.

The check is new with commit 4008758105a6 and was added with the goal of
allowing non-root users to create VMs in mind. Just remove it for now.

Reported by: Alonso Cárdenas Márquez <acardenas@bsd-peru.org>
Reviewed by: jhb
Fixes: 4008758105a6 ("vmm: Validate credentials when opening a vmmdev")
Differential Revision: https://reviews.freebsd.org/D46535

show more ...

vmm: Use make_dev_s() to create vmm devices

This avoids creating windows where a device file is accessible but the
device-specific field is not set.

Now that vmmdev_mtx is a sleepable lock, avoid d

vmm: Use make_dev_s() to create vmm devices

This avoids creating windows where a device file is accessible but the
device-specific field is not set.

Now that vmmdev_mtx is a sleepable lock, avoid dropping it while
creating devices files. This makes it easier to handle races and
simplifies some code; for example, the VSC_LINKED flag is no longer
needed.

Suggested by: jhb
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D46488

show more ...

vmm: Use an sx lock for vmmdev_mtx

This will make it easier to atomically create the device file and set
its si_drv1 member.

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

vmm: Use an sx lock for vmmdev_mtx

This will make it easier to atomically create the device file and set
its si_drv1 member.

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

show more ...

vmm: Validate credentials when opening a vmmdev

Rather than performing privilege checks after a specific VM's device
file is opened, do it once at the time the device file is opened. This
means tha

vmm: Validate credentials when opening a vmmdev

Rather than performing privilege checks after a specific VM's device
file is opened, do it once at the time the device file is opened. This
means that one can continue to access a VM via its device fd after
attaching to a jail which does not have vmm enabled, but this seems like
a reasonable semantic to have anyway.

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

show more ...

vmm: Harmonize compat ioctl definitions

For compat ioctls and structures, we use a mix of suffixes: _old,
_fbsd<version>, _<version>. Standardize on _<version> to make things
more consistent. No f

vmm: Harmonize compat ioctl definitions

For compat ioctls and structures, we use a mix of suffixes: _old,
_fbsd<version>, _<version>. Standardize on _<version> to make things
more consistent. No functional change intended.

Reported by: jhb
Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D46449

show more ...

vmm: Let devmem devices reference the VM credential

Otherwise they are globally visible (in jails with allow.vmm set),
instead of being restricted to the jail to which the VM belongs.

Reviewed by:

vmm: Let devmem devices reference the VM credential

Otherwise they are globally visible (in jails with allow.vmm set),
instead of being restricted to the jail to which the VM belongs.

Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D46448

show more ...

vmm: Be more consistent with the credential used for VM lookup

vmmdev_lookup() is used from sysctl context to find a VM by name.
There, a reference credential is already passed, so use that instead

vmm: Be more consistent with the credential used for VM lookup

vmmdev_lookup() is used from sysctl context to find a VM by name.
There, a reference credential is already passed, so use that instead of
assuming that it's the same as curthread->td_ucred, even though that's
true today. No functional change intended.

Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D46447

show more ...

vmm: Remove an unneeded lookup in devmem_create_cdev()

The sole caller of this function already holds a pointer to the VM's
softc, so rather than passing the VM name and looking it up again, just
pa

vmm: Remove an unneeded lookup in devmem_create_cdev()

The sole caller of this function already holds a pointer to the VM's
softc, so rather than passing the VM name and looking it up again, just
pass the softc pointer directly. This function is only called from an
ioctl context, so the softc structure will remain live.

Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D46446

show more ...

vmm: Factor most of sysctl_vmm_destroy() into a separate function

This will make it easy to share code with an ioctl handler which creates
VMs. No functional change intended.

Reviewed by: corvink,

vmm: Factor most of sysctl_vmm_destroy() into a separate function

This will make it easy to share code with an ioctl handler which creates
VMs. No functional change intended.

Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D46445

show more ...

vmm: Factor most of sysctl_vmm_create() out into a separate function

This will make it easy to share code with an ioctl handler which creates
VMs. No functional change intended.

Reviewed by: corvi

vmm: Factor most of sysctl_vmm_create() out into a separate function

This will make it easy to share code with an ioctl handler which creates
VMs. No functional change intended.

Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D46444

show more ...

vmm: Move compat ioctl definitions to vmm_dev.c

There is no reason to keep them in vmm_dev.h. No functional change
intended.

Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebs

vmm: Move compat ioctl definitions to vmm_dev.c

There is no reason to keep them in vmm_dev.h. No functional change
intended.

Reviewed by: corvink, jhb
Differential Revision: https://reviews.freebsd.org/D46432

show more ...

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