Date: Sat, 05 Dec 2015 14:03:20 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-virtualization@FreeBSD.org Subject: [Bug 203820] kernel panic when trying to unload vmm(4) and VirtualBox VMs are running Message-ID: <bug-203820-27103-KkMKsP2csY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-203820-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-203820-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203820 John Baldwin <jhb@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #5 from John Baldwin <jhb@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-203820-27103-KkMKsP2csY>