vmm: Add a device file interface for creating and destroying VMs

[markj]

Summary

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.

[emaste]

Would it make sense to use an nvlist (and avoid the reserved array)?

[markj]

In D47028#1076694, @emaste wrote:

Would it make sense to use an nvlist (and avoid the reserved array)?

At this point, not particularly. I don't foresee this interface growing a lot of functionality, since VM configuration is generally done using a set of follow-up ioctls. The reserved fields are there just in case, as they're basically free.

Maybe someday it'd be nice to have an nvlist-based interface, but it's easy to switch to that later.

[jhb]

Historically I had wanted the 'maxcpus' tunable to be one of the possible settings at creation time (and an nvlist is how I would have passed in such settings). However, I think I've mostly made that requirement OBE in practice.