A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

AMD-V issue using Virtualbox 3.1.x on Ubuntu Karmic

It seems that Virtualbox 3.1.x now implements a quick check to see if the hardware virtualization extensions are in use before launching AMD-V enabled guests. There seem to be two key issues with this change

  1. Buggy BIOS’s that do not clear a VERR_SVM_IN_USE flag properly on boot
  2. KVM modules that set the VERR_SVM_IN_USE flag when they load on boot

Either of these issues will prevent a VirtualBox 3.1.x guest from loading with AMD-V virtualization enabled. Depending on what type of guest you are running, you may not even notice this issue. Some virtualized 64-bit guests may not even operate as they require the extensions to boot (vt-x error message). Other virtualized 32-bit guests, like my Windows XP 32-bit guest, will load without the hardware virtualization extensions running resulting in a performance hit. In this second case, if the little computer chip icon with the “V” is faded then you are not using the AMD-V extensions. Shown below is a working VirtualBox guest with active AMD-V (not faded) icon highlighted as it should be normally.
Windows 32 VirtualBox Guest

Any system that shows “svm” in /proc/cpuinfo may benefit from AMD-V extensions running a virtualized guest OS. On my dual core laptop this looks like:

imac@dv7z:~$ cat /proc/cpuinfo | grep svm
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch osvw skinit
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch osvw skinit

Examining the second issue, the current qemu-kvm package loads kvm which sets the VERR_SVM_IN_USE flag checked by Virtualbox, even if the modules technically are not in use (IMHO, this seems like a kvm module bug to set this flag). One workaround if you have the issue described above is to disable the kvm extensions using module blacklisting, and modify the qemu init scripts to honour the blacklisting configuration.

Step 1: Apply a quick patch to /etc/init.d/qemu-kvm, adding --use-blacklist to the code snippet below as stated in this Ubuntu bug report. This should appear in Karmic *proposed* sometime soon.

case "$1" in
start)
log_begin_msg "Loading kvm module $module"
if [ -z "$module" ]
then
log_end_msg 1
exit 0
fi
if modprobe --use-blacklist "$module"
then
log_end_msg 0
else
log_end_msg 1
exit 1
fi
;;

Step 2: Create a blacklist configuration file in /etc/modprobe.d to prevent loading of the kvm modules. My configuration contained in a file I created/etc/modprobe.d/blacklist-kvm-im.conf is below, noting I used my initials in the filename to distinguish it from any current or future configuration files deposited by the package management system. Perhaps VirtualBox will ship with a similar one if this issue is not resolved with the KVM maintainers.

imac@laptop:~$ cat /etc/modprobe.d/blacklist-kvm-im.conf
#Workaround for KVM setting VERR_SVM_IN_USE flag
blacklist kvm
blacklist kvm_amd
imac@laptop:~$

Once completed the system should load without kvm confirmed by a quick check of running modules:

imac@laptop:~$ lsmod | grep kvm
imac@laptop:~$

Examining the first issue (Buggy BIOS), the simple thing to do would be to upgrade to a patched BIOS. Assuming the latest BIOS does not solve this problem, the second solution is to load the kvm_amd module and then unload it using the rmmod command. This actually clears the flag, and can be implemented in a simple startup script to work around a buggy BIOS until which point the kvm_amd module behaves differently (IMHO, it really should not set this flag until it is in use, and likely should also detect an IN_USE conflict similar to VirtualBox) and/or a BIOS upgrade/alternate workaround exists.

VirtualBox AMD-V guests should load just like the XP screenshot shown above. This issue is being tracked in various places, including the following related links:

Share

1 comment to AMD-V issue using Virtualbox 3.1.x on Ubuntu Karmic

Leave a Reply