vmm: Postpone vmm module initialization to after SI_SUB_DEVFS

vmmops_modinit() needs to create a device file, and this must happen
after SI_SUB_DEVFS. On non-EARLY_AP_STARTUP platforms (i.e., !x86)

vmm: Postpone vmm module initialization to after SI_SUB_DEVFS

vmmops_modinit() needs to create a device file, and this must happen
after SI_SUB_DEVFS. On non-EARLY_AP_STARTUP platforms (i.e., !x86) this
happens already by accident, but we shouldn't rely on it.

On riscv, remove the current SI_SUB_SMP ordering since that was copied
from arm64 and isn't needed. In particular, riscv's vmmops_modinit()
does not call smp_rendezvous().

Reported by: Oleksandr Kryvulia <shuriku@shurik.kiev.ua>
Fixes: a97f683fe3c4 ("vmm: Add a device file interface for creating and destroying VMs")

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: fix vcpu atomic load

Load vcpu with acquire semantics as we are making a critical code
section between creating vcpu and using it.

Tested on risc-v only.

Pointed out by: markj
Reviewed by: jh

vmm: fix vcpu atomic load

Load vcpu with acquire semantics as we are making a critical code
section between creating vcpu and using it.

Tested on risc-v only.

Pointed out by: markj
Reviewed by: jhb, markj
Differential Revision: https://reviews.freebsd.org/D47306

show more ...