[Bug 203820] kernel panic when trying to unload vmm(4) and VirtualBox VMs are running

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Dec 5 14:03:21 UTC 2015


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203820

John Baldwin <jhb at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jhb at FreeBSD.org

--- Comment #5 from John Baldwin <jhb at FreeBSD.org> ---
In general I think VM monitors assume that no other monitors are running.  I
believe OS X has a kernel-level API for monitors to use to try to mitigate
this, but FreeBSD does not.  For example, I fixed bhyve VMs to work across
suspend and resume (of a host laptop), but that fix is specific to bhyve and
does not support other VM monitors.

In general VM monitors like bhyve assume that they "own" all of the VT-x (or
SVM) state.  They assume they are not sharing it.  Just loading vmm.ko will
_set_ various CPU control registers (MSRs) related to VT-x (VT-x includes a
host of optional features that can be enabled selectively) which might confuse
some other VMM that had set these controls to different values.  (For bhyve see
the sys/amd64/vmm/vmx/vmx.c vmx_init() routine run by vmm_init() in
sys/amd64/vmm/vmm.c on module load.)

In summary, it is not safe to even load multiple VMMs at the same time, much
less run VMs from different VMMs concurrently.  If FreeBSD does grow an API to
support VM monitors the first iteration of it will probably fail attempts to
load more than one VMM for this reason.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-virtualization mailing list