OS-6617: remove forceload for viona and vmm from /etc/system
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2018-03-02T16:29:53.616Z)
2018-03-15 Nibelheim (Release Date: 2018-03-15)
- is depended on by OS-6615 land bhyve in master
- is related to OS-6614 vmm should allow various zones to have instances by same name
/etc/system has forceload entries for
viona so that they are available when
zhyve starts in a bhyve zone. A different mechanism should be used to ensure that the drivers are loaded prior to booting a bhyve zone so that the device files are available to
Comment by Mike Gerdts
Created at 2018-02-22T21:03:28.781Z
In chat, we discussed
the possibility of creating
plugin. This would give us the on-demand loading of the
is starting. OS-6616 has already solved this for
Comment by John Levon
Created at 2018-02-22T21:09:48.762Z
A little more detail:
sdev plugins are registered at module load time. During boot, pseudo nexus enumeration will load the vmm driver, and hence register the /dev/vmm plugin. However, there is nothing to keep this plugin loaded. If the driver modules is unloaded, then sdev plugin code will remove /dev/vmm and there's nothing to demand load the module on a readdir(/dev/) or lookup(/dev/vmm).
We'll cut this Gordian knot by moving /dev/vmm/ctl to /dev/vmmctl and introducing a devfsadm plugin for it. This will make this act like any other normal pseudo node: sdev will keep around a stale /dev/vmmctl sdev_node, and drop into devfs_lookup(), which will indirectly trigger the module load as needed, and the plugin for /dev/vmm.
This works in context because vmm module will stay loaded while VMs exist, and bhyve will always call into /dev/vmmctl before trying to use /dev/vmm.
Comment by Jira Bot
Created at 2018-03-02T16:14:23.240Z
illumos-joyent commit 7bb94c96d6b670e5ac129648edfd9d3734953514 (branch master, by John Levon)
OS-6617 remove forceload for viona and vmm from /etc/system
OS-6679 ABBA deadlock in vmm sdev plugin
Reviewed by: Mike Gerdts <email@example.com>
Reviewed by: Jerry Jelinek <firstname.lastname@example.org>
Approved by: Patrick Mooney <email@example.com>