Bug 212918 - Host system hangs after suspend/resume if emulators/virtualbox-ose VirtualBox VMs are running
Summary: Host system hangs after suspend/resume if emulators/virtualbox-ose VirtualBox...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: crash, needs-qa
: 253963 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-09-23 08:43 UTC by Aleksander Alekseev
Modified: 2024-11-25 13:02 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aleksander Alekseev 2016-09-23 08:43:37 UTC
Steps to reproduce:

1. Launch some virtualbox VMs
2. sudo acpiconf -s 3
3. Resume

Expected behavior:

System continue to run.

Actual behavior:

Black screen, system doesn't respond to any hotkeys. Impossible to reboot a system by typing commands blindly or create a kernel dump using Ctr+Alt+F1, Ctr+Alt+Escape.

Hardware: Fujitsu Lifebook E733

uname -a:
```
FreeBSD e733 11.0-RC3 FreeBSD 11.0-RC3 #0 r305786: Wed Sep 14 02:19:25 UTC 2016     root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
```

Naturally it could be a bug in virtualbox driver or port, not FreeBSD kernel itself.
Comment 1 Aleksander Alekseev 2016-09-23 08:47:01 UTC
```
$ pkg info | grep virtualbox
virtualbox-ose-5.0.26          General-purpose full virtualizer for x86 hardware
virtualbox-ose-kmod-5.0.26_1   VirtualBox kernel module for FreeBSD
```
Comment 2 Igor Osminin 2021-03-03 18:45:49 UTC
*** Bug 253963 has been marked as a duplicate of this bug. ***
Comment 3 Jason W. Bacon freebsd_committer freebsd_triage 2022-05-02 19:43:46 UTC
I also consistently see a panic upon resume with 13.0-RELEASE and virtualbox-ose-6.1.34.  This only happens when a VM is running.
Comment 4 Tamas Szakaly 2022-06-29 06:01:39 UTC
Hello!

Someone mentioned turning off exclusive use of hardware virtualization in a freebsd-hackers discussion about running VirtualBox and bhyve side by side (https://lists.freebsd.org/archives/freebsd-hackers/2022-June/001299.html). I had a hunch that this setting might also affect this issue, turned it off (vboxmanage setproperty hwvirtexclusive off), and now I can suspend/resume the host with running VMs. So this seems to be a good workaround, and also might narrow down the issue.
Comment 5 Jason W. Bacon freebsd_committer freebsd_triage 2022-06-29 13:03:56 UTC
(In reply to Tamas Szakaly from comment #4)

Far out...

Just verified that this works for FreeBSD 13.1-RELEASE and virtualbox-ose-6.1.34.

Thanks!
Comment 6 Jason W. Bacon freebsd_committer freebsd_triage 2022-10-12 11:23:29 UTC
Maybe the port could be patched so hwvirtexclusive is off by default?
Comment 7 Graham Perrin freebsd_committer freebsd_triage 2023-08-18 20:06:44 UTC
Duplicate of bug 155964?

> 155964 – OS hangs completely when suspend/resume with 
> active emulators/virtualbox-ose VirtualBox guest window
Comment 8 Jason W. Bacon freebsd_committer freebsd_triage 2024-04-26 11:55:36 UTC
Is this still an issue?  I haven't had this problem anymore in recent FreeBSD releases.
Comment 9 fabio.comolli 2024-11-09 20:15:53 UTC
(In reply to Jason W. Bacon from comment #8)

It is. Replicated twice today vith 6.1.50_5 running under 14.1-release-p6.
Comment 10 fabio.comolli 2024-11-09 20:19:00 UTC
(In reply to fabio.comolli from comment #9)

... and replying to myself: I also confirm that "vboxmanage setproperty hwvirtexclusive off" makes suspend / resume (with a Virtualbox VM open, of course) work.
Comment 11 Jason W. Bacon freebsd_committer freebsd_triage 2024-11-24 14:56:56 UTC
To patch in a workaround, I think we would need to insert

vboxmanage setproperty hwvirtexclusive off

before a VM is started by any method.  There are multiple ways to launch a VM from the command line (VirtualBox, VboxHeadless, VBoxManage startvm, etc.)  I wonder if they all lead to a single point in the code where the VM process is started, or if the start code is replicated in multiple places.  This will require a little digging...
Comment 12 Jason W. Bacon freebsd_committer freebsd_triage 2024-11-24 19:40:00 UTC
As an alternative, I may have found the place where this is initialized in src/VBox/Main/src-server/SystemPropertiesImpl.cpp.  Maybe just adding FreeBSD to the OS list here (and an appropriate comment explaining why) would do the trick.

    /* On Windows, OS X and Solaris, HW virtualization use isn't exclusive
     * by default so that VT-x or AMD-V can be shared with other
     * hypervisors without requiring user intervention.
     * NB: See also SystemProperties constructor in settings.h
     */
#if defined(RT_OS_DARWIN) || defined(RT_OS_WINDOWS) || defined(RT_OS_SOLARIS)
    m->fExclusiveHwVirt = false;
#else
    m->fExclusiveHwVirt = true;
#endif
Comment 13 Jason W. Bacon freebsd_committer freebsd_triage 2024-11-25 13:02:57 UTC
(In reply to Jason W. Bacon from comment #12)

Not going to be that easy.  I reinstalled from source with the patch below, and it did not help.  System panicked immediately on resume.

--- src/VBox/Main/src-server/SystemPropertiesImpl.cpp.orig      2024-01-11 12:25:27 UTC
+++ src/VBox/Main/src-server/SystemPropertiesImpl.cpp
@@ -105,8 +105,9 @@ HRESULT SystemProperties::init(VirtualBox *aParent)
      * by default so that VT-x or AMD-V can be shared with other
      * hypervisors without requiring user intervention.
      * NB: See also SystemProperties constructor in settings.h
+     * FreeBSD systems panic on sleep/resume with exclusive enabled.
      */
-#if defined(RT_OS_DARWIN) || defined(RT_OS_WINDOWS) || defined(RT_OS_SOLARIS)
+#if defined(RT_OS_DARWIN) || defined(RT_OS_WINDOWS) || defined(RT_OS_SOLARIS) || defined(RT_OS_FREEBSD)
     m->fExclusiveHwVirt = false;
 #else
     m->fExclusiveHwVirt = true;