Possible Bug With Linux Host and Broadwell CPU's (SMAP feature)

[tascheitrum]

I received a Dell latitude e7450 (Broadwell CPU) and as noted in my forum post, Virtualbox Hangs at "0% Starting Virtual Machine". According to the log files it never actually gets to the boot sequence. ​https://forums.virtualbox.org/viewtopic.php?f=7&t=65932

I noticed another person with a Broadwell CPU was having the same problem here: ​http://askubuntu.com/questions/581301/virtualbox-stuck-on-starting-virtual-machine/583628

And that leads me to believe that there may be a bug in Virtualbox on Linux Hosts and Broadwell CPU's.

To be clear, I enabled Virtualization support in my bios, did a fresh install of Mint 17.1, only installed virtualbox and added my user to vboxusers and it will not boot. If I reboot and load my Windows 7 Partition, Virtualbox works just fine, so the hardware is capable of virtualization, and it works, just not with a Linux host.

I've attached logs, hopefully they shed some light on the issue!

[tascheitrum]

Guest Machine Logs

[tascheitrum]

I've also tried booting with 'Enable I/O APIC' and 'Use Host I/O cache' to no avail. and am using (i think) the latest build 4.3.20 r96996 with kernel 3.16.0-30-generic (I've tried previous kernels too, also didn't work)

[Frank Mehnert]

I have a suspicion. Please add the following files:

• the configuration of your host Linux kernel
• the complete output of 'dmesg' after you tried to start a VM

[Frank Mehnert]

And after your provided the files, could you test if you are able to start your VM with 'nosmap' added as kernel parameter (host kernel)?

[tascheitrum]

Replying to frank:

And after your provided the files, could you test if you are able to start your VM with 'nosmap' added as kernel parameter (host kernel)?

Thanks for the help, I don't have the computer in front of me but after work I can get you the requested information.

[tascheitrum]

dmesg and kernel config from failed boot

[tascheitrum]

Success!

Virtualbox will boot with 'nosmap' added as a host kernel parameter!

What does this command do? Does it have any affect on my system, or should I put that in my kernel boot parameters permanently?

[Frank Mehnert]

Broadwell CPUs introduce a new feature called 'supervisor mode access prevention' which allows to restrict kernel code from directly accessing usermode code. The intention is to catch bugs in kernel code because normally the kernel would access user-level memory only under rare conditions (mostly when copying parameters for system calls from/to user memory prior/after the system call is executed). For historic reasons, VirutalBox kernel code needs to access user-level code because the complete virtual memory of the guest is mapped on the host side and on 32-bit hosts we have the 1G limitation in the kernel part of the address space (3G for userland, 1G for kernel, kernel starts at 0xC0000000). And we don't want to limit guests on 32-bit hosts to 1GB RAM...

[Frank Mehnert]

Disable SMAP when during VirtualBox kernel calls

[Frank Mehnert]

So all affected users: Please could you apply the diff_4.3_smap patch to your host kernel module and verify that it solves your problem:

cd /usr/src/vboxhost-4.3.20
sudo -s
patch -p1 < diff_4.3_smap
/etc/init.d/vboxdrv setup

Of course adapt the path to the diff file accordingly. After applying the patch please make sure to remove the nosmap parameter from the kernel command line.

Please let me know if that patch solves your problem the need to add any additional kernel parameters. Unfortunately I don't have Broadwell hardware handy and therefore cannot test this patch myself. Thank you!

[MichaelAquilina]

I'm the user who posted the issue on stack overflow. I'll be able to test using nosmap tomorrow and report back here.

[Frank Mehnert]

Thanks. I would appreciate if you could also test the patch. :-)

[lcd]

The patch works on virtualbox version 4.3.18-dfsg-1~ubuntu1~trusty1.

I had the problem with a new Dell E5450 laptop.

Patched the file and ran "dpkg-reconfigure virtualbox-dkms"

That fixed the problem.

[MichaelAquilina]

Out of curiosity what are the empty inline calls to stac and clac doing in your diff?

[tascheitrum]

I tested the patch on Virtualbox 4.3.20 r96996 and it seems fixed.

THANK YOU Frank!

If you have a preferred method of donation, i'd be happy to buy you a beer!

[Frank Mehnert]

MichaelAquilina, the empty inline functions are only required for older kernels without SMAP support (older than Linux 3.7) to make the compiler happy.

Thanks for all the feedback. The patch will be part of the upcoming next maintenance release.

[MichaelAquilina]

Both nosmap as a kernel parameter and the diff you provided work for me. Thanks for all the help. As taschitrum mentioned, if you have a preferred method of donation let me know :)

[Frank Mehnert]

Fix is part of VBox 4.3.22.

[corentin]

I have a Thinkpad x1 carbon 2015, with Virtualbox 4.3.26 and could not have my VMs starting. I've tried Fedora 21 & 22 where the Desktop freezes, Debian 8 where as the OP described only Virtualbox hanged up (for me at 20%). Finally I've tried the nosmap kernel option, and it did the job.

I haven't tried the nosmap fix before because I thought it was already fixed in my Virtualbox release.

I'm commenting here, don't know if it should be reopen, maybe it will encourage other readers to give a shot to the osmap kernel option. I'm available if one needs more input.

Original help request: ​https://forums.virtualbox.org/viewtopic.php?f=7&t=67516

[Frank Mehnert]

corentin, please go to #13961 and use the included diff_smap_4 Patch in that ticket.