vmm: Use an sx lock to protect the memory map.

[jhb]

Summary

Previously bhyve obtained a "read lock" on the memory map for ioctls
needing to read the map by locking the last vCPU. This is now
replaced by a new per-VM sx lock. Modifying the map requires
exclusively locking the sx lock as well as locking all existing vCPUs.
Reading the map requires either locking one vCPU or the sx lock.

This permits safely modifying or querying the memory map while some
vCPUs do not exist which will be true in a future commit.

[markj]

Typo in your commit log, modififying

Maybe you add one in a follow-up revision, but I think it'd be useful to document the locking protocol somewhere.

sys/amd64/vmm/vmm.c

727

Assert that the lock is held here?

782

Assert that the lock is held?

sys/amd64/vmm/vmm_dev.c

1269

This applies to the old code, but it seems a bit dubious that we increase the object refcount after dropping the lock. vmmdev_mmap_single() does not have this problem.

[jhb]

sys/amd64/vmm/vmm.c

782

It's not held by vm_cleanup(). I could add the assert but would need to add (somewhat pointless) locking in vm_cleanup().

sys/amd64/vmm/vmm_dev.c

1269

I'll add a followup.

[jhb]

Add assertion and locking key

[jhb]

Add locking key for rendezvous_mtx