AMD-V not working: VERR_SVM_IN_USE -> update your BIOS/workaround available in SVN/3.1.4

VBox 3.1.0 log after unsuccessful attempt to open 64 bit guest

I have the identical symptoms, using AMD Phenom II X4 940, Gigabyte GA-MA78GM-S2HP motherboard, Host OS: Ubuntu 9.10 64bit, GuestOS: Win 7 64; Ubuntu 9.10 64, virtualization enabled in BIOS.
I discovered the same thing, that is, Remove 3.1.0 -> install 3.0.12 -> remove 3.0.12 -> install 3.1.0 and the 64 bit guests work until I restart the computer. See this post on the VBox forum http://forums.virtualbox.org/viewtopic.php?f=7&t=25436

My log file is attached (following an unsuccessful attempt to start a 64 bit guest).

Somebody else has claimed ownership of AMD-V. Make sure no other hypervisors (KVM) are active.

Same problem. Configuration AMD Phenom II X4 955, Gigabyte GA-MA78GPM-DS2H motherboard, Host OS: Windows 7 Ultimate 64bit, GuestOS: any. Same problem. No other virtualization package installed. Looking like a motherboard interaction, I guess, but it would be really useful to know what the change was from 3.0.12 to 3.1.0, so that if it's not a VirtualBax? issue, we can at least try to resolve it with Gigabyte.

Logs attached.

Logs for 3.1.0 failure and 3.0.12 success

winds350: try to find a BIOS update if you are sure about that. XP compatibility mode in Windows 7 also uses AMD-V.

VirtualBox 3.1.0 performs stricter checking to see if AMD-V is in use. Previous versions contained a bug that disabled the check.

Sander: I think that if a feature (AMD-V) worked before 3.1, it should work now, with 3.1.

The "stricter" check seems to cause problems. Why is it needed?

-Technologov

Quite obvious: to avoid conflicts with other hypervisors. Absolutely necessary with XP compatibility mode in Windows 7.

I don't have XP compatibility mode installed. I'm guessing about the motherboard interaction based on the same family board in the three reports here. I'm running the latest BIOS, so no joy there.

It's odd that we've all seen it work after an upgrade from 3.0.12 to 3.1.0, but not after a subsequent reboot.

Somebody else is turning on EFER.SVME. A likely candidate is the BIOS. The same problem should also show up when installing the XP compatibility mode extension for Windows 7.

3.0.12 clears this bit after running a VM, so that explains why 3.1.0 didn't complain.

OK, so if I understand correctly, this extra check is like electrical fuse.

Some buggy BIOSes report that hardware virtualization is used.

It happens to work with v3.0.12 because to starts hardware virtualization without check, and it happens to work, because no other virtualization really uses it. but if other virtualizer works at the same, it will crash the host.

*But* (And this is a big but) I would prefer to have some workaround for the buggy BIOSes for advanced users (who understand the risk). Would it be possible to provide this risky option (to disable the fuse) ?

Making a special global parameter (VBoxManage setextradata) or Host environment parameter to override buggy BIOSes...

Sander: does it sound OK for you ?

I just went to the Gigabyte support website and found a newer version of BIOS for my GA-MA78GM-S2HP motherboard. I was running F5b, a beta version that fixed a problem with running memory in dual channel mode.

I downloaded version F5 final (2009/06/23) and after updating the BIOS, VBox 3.1.0 doesn't complain about VERR_SVM_IN_USE any more and my 64 bit guests run OK after a reboot. I will do some more testing but it does look like an issue with the Gigabyte MB and its BIOS handling of EFER.SVME as Sander has deduced.

Great. Thanks for the feedback.

Encouraging. Just noticed there is a beta version for my GA-MA78GPM-DS2H board, version F6C. I'm currently running F5 dated 2009/06/01 with no joy. I'll try the beta. If not, I'll start leaning on Gigabyte.

BIOS F6C for Gigabyte GA-MA78GM-S2HP motherboard fixes the problem. Thanks sandervl73 for sticking with us while we figured it out, and thanks rawj for reporting back once you had resolved it with a BIOS change.

* not working: VERR_SVM_IN_USE -> update your BIOS. Great. Thanks for the feedback.

Of, thank you, sandervl73, a ton! What about "Does not work for me" with AMD Athlon(tm) 64 X2 Dual Core Processor 6000+?

$ grep -q svm /proc/cpuinfo && echo 'Has support for AMD-V' 
Has support for AMD-V

Why should I bother looking up for BIOS update (which actually could be not even released), do that update (if actually there was an update) and reboot my system?

Why /proc/cpuinfo's information isn't sufficient after all?

There seems to be a large number of buggy AMD systems in circulation... according to the amount of reports.

I think the proposed by me workaround is the reasonable middle ground.

Would it be easy to provide this ?

-Technologov

Same problem with my GA-MA78GM-S2H (rev 2), Bios Ver. FC

I contacted Gigabyte Support whether they could provide an update, in case they won't I hope that VBox can offer some workaround (at least for advanced users on own risk)

Asus M4A78 same problem. Newest bios didn't help:(

Replying to akukalle:

Asus M4A78 same problem. Newest bios didn't help:(

After installation 3.1 worked fine. Problem happened after restarting the host.

Just adding more data points.

GA-MA78GM-US2H motheroard, Phenom X4 810 cpu, 8G ram, ubuntu 9.10.

Updated BIOS to F8 (the latest on gigabyte's site), still does not work with 3.1.0.

Like others have found, if I start a 64bit vm under 3.0.12, then remove it and upgrade to 3.1.0, the 64bit vm works under 3.1.0.

Same here. Gygabite MA790GPT-UD3H with amd x4 645 BIOS F3 and F4B Ubuntu 9.10 64 bits Host, M$ 32/64bits guest. "Virtualization" Enabled in BIOS Removed powercord for a minute vmware installed but not running

It worked on 3.0.10(REALLY SLOW when smp guest,in fact 1 core guest were much faster than 2core guest,4 core win guest tooks about 8 minutes to boot) then upgraded to 3.1 and not starting anymore.

Launching 64bits guest warn about vt enabled but no usable Launching 32bits guest raises an errorVT-x is not available. (VERR_VMX_NO_VMX)

Intel Atom 330, ZOTAC 330-IONITX-A-E motherboard, newest available BIOS, clean install of Karmic64bit at host, clean instal VBox, no virtual machines before, new machine added, ddl Lucid 64bit iso and it claims that I have no 64bit hardware at all.

dk75: this ticket is about AMD CPUs. Afaik Atom CPUs don't support VT-x

Actually, some Atoms _do_ support VT-x.

See: http://ark.intel.com/ProductCollection.aspx?familyId=29035

-Technologov

Ah, I see... that not mine. Forget then.

I also suffered from this issue. It surfaced after trying out KVM (which wasn't a good experience, by the way). I thought I had thoroughly deleted KVM, but found out qemu-kvm was still installed.

For anyone having this issue, try something like 'sudo apt-get remove kvm*'. I don't know how to tell kvm to not use AMD-V when it is not on.

3.1.2 is out. Does someone know have they fixed that issue in that release?

Replying to poige:

3.1.2 is out. Does someone know have they fixed that issue in that release?

No, bug is also in 3.1.2 I'm using Ubuntu 9.10 amd64, VirtualBox 3.1.2. I hit this issue when starting guest with multi CPU. No problem was in VirtualBox 3.0.8 Workaround for me is "modprobe -r kvm_amd" or better uninstall qemu-kvm.

Replying to poige:

3.1.2 is out. Does someone know have they fixed that issue in that release?

My previous suggestion worked only until the next reboot. I'm thus still experiencing this problem, also with 3.1.2. I've disabled "Secure Virtual Machine mode" in my BIOS, but that doesn't change a thing.

My system:
Motherboard: Asus M4A78T-E
Chipset: AND 790GX
CPU: AMD Phenum II x4 810
GPU: Integrated Radeon HD3300

Replying to jaromir.obr:

Workaround for me is "modprobe -r kvm_amd" or better uninstall qemu-kvm.

I tried both of these, but uninstalling qemu-kvm only works untill the next reboot, and "modprobe -r kvm_amd" only works with kvm installed, wich I don't want. Are there any other options?

-r kvm_amd" only works with kvm installed, wich I don't want. Are there any other options?

A proper BIOS would be helpful! ;)

Well, seriously... I got a reply from Gigabyte support where they claim that their boards don't support AMD-V! That's ridiculous since I even have an BIOS switch for en-/disabling AMD-V.

My suggested workaround: Code a small superuser tool which sets the "AMD-V in use" cpuflag to false. We could run this tool at every boot time of the host computer.

EFER.SVME = EFER.SVME & (~(1 << 12));

Would this work? ;-)

I have the same problem. I had an AMD Athlon 64 X2 5000+ and I was able to use AMD-V and Nested Paging. When I upgraded Virtualbox, I was unable to use AMD-V and Nested Paging. I now have an AMD Phenom II 965 Black Edition and I can't use AMD-V or Nested Paging. My motherboard is an MSI K9N2G Neo-FD with the latest BIOS update.

AgentE382

Hi

Just to add to the trail (accidentally opened another ticket 5888 - getting that closed)

I have a gigabyte GA-MA790FXT-UD5P AMD Phenom(tm) II X4 945 Processor

same symptoms - worked 3.0.8, not working with 3.1.

I would be happy to have a little util that cleared the flag :)

Replying to initzero:

{{{ EFER.SVME = EFER.SVME & (~(1 << 12)); }}} Would this work? ;-)

Could you share which headers to include to compile the statement of code you posted? I searched a bit through the code of VirtualBox, but I couldn't find a reference to it.

Went through the bios upgrade process (http://www.gigabyte.com.tw/Support/Motherboard/BIOS_Model.aspx?ProductID=3005) and now it seems like it is working.

Thanks for all the info on the thread.

Note - if it hadn't worked I would still have been happy to use app to clear flag

My HP dv5-1008ca running Karmic exhibits this same issue. I am running the latest BIOS from HP (F.37) and see this in my XP Guest logs now after upgrading from 3.0.12 to 3.1.2.

00:00:02.799 HWACCM: No VT-x or AMD-V CPU extension found. Reason VERR_SVM_IN_USE

Interestingly, I have also always had the kvm_amd module running in my kernel with 3.0.12, as I have some kvm stuff too. This has never caused issues with VirtualBox in the past.

root@n8-laptop:~# lsmod | grep kvm kvm_amd 41556 0 kvm 190616 1 kvm_amd

Simply performing an rmmod kvm_amd solved my provlem, and now AMD-V is back in my XP Guest.

If this is not a bug, then it would make sense that kvm_amd setting VERR_SVM_IN_USE is actually the bug, as it should not be set until the VM is loaded? I assume that VERR_SVM_IN_USE is set when VirtualBox loads the AMD-V enabled guest?

Looks like KVM has an issue with VirtualBox modules now too. This bug report does not specify the VirtualBox version, but suggests that the modules are (or were previously) mutually exclusive. http://sourceforge.net/tracker/?func=detail&aid=2793994&group_id=180599&atid=893831

I reported duplicate bug. Since installing 3.1 Virtualbox stopped working with 64-bit guests. I use AMD X2 virtualization-capable CPU, it works flawless on 3.0 series. Host system is XUbuntu LTS 8.04 Hardy 64-bit, guests are debian 64bit, fedora 64bit, etc and all refuse ro recognise amd-v instructions and keep popping up error message about not finding Intel Vt.. ? Installing back to 3.0.

Oh, yes forgot to mention, Amd X2 3600+, Biostar 680G Am2 Motherboard, no any newer Bios available, works on 3.0 virtualbox.

I also have Asus M4A78 with the newest bios which has this problem (as others have already stated). Would love to have a way to clear that flag. In the meantime... sounds like downgrading to 3.0.x is the best workaround? Wasn't sure if downgrade might corrupt my image

same here on a Dell inspiron 546 with AMD Athlon(tm) 64 X2 Dual Core Processor 5200+

VirtualBox 3.0 worked fine but 3.1.2 gives me this nasty vt-x error.

i already went looking in my bios and the only option i could find is: 'amd virtualization' and that is already set to: 'enabled'

there arent any other bios options concerning this....

Several people in our office have worked around this issue, as the kvm modules simply conflict irrespective of BIOS settings, etc. Perhaps there are two issues here (one with kvm, and another with buggy BIOS's) but I'd just like to re-iterate that so far I have had 100% success working around this issue by removing the kvm conflict on three separate systems. In Ubuntu blacklisting the module does not work completely, as there are other utilities like qemu that do not obey blacklisting rules, making the workaround somewhat more involved.

Ubuntu users, and possibly others, may benefit from this post describing how to solve this issue on Karmic (9.10). http://www.ianbmacdonald.com/wordpress/2010/01/11/amd-v-issue-using-virtualbox-31x-on-ubuntu-karmic

In my case I'm on Gentoo and I see no signs of the kvm modules: jj dave # lsmod | grep kvm jj dave #

While it may be a buggy BIOS sounds like my only option is to downgrade virtualbox

Replying to mankiko:

In my case I'm on Gentoo and I see no signs of the kvm modules: jj dave # lsmod | grep kvm jj dave # While it may be a buggy BIOS sounds like my only option is to downgrade virtualbox

You could also as a workaround install the kvm modules. As the kvm_amd module cleares the flag when it is removed from the kernel, simply running

rmmod kvm_amd

will allow the virtual machines to be started.

I think that there are multiple bug reports that are set as duplication of this bug and they actually say that Virtualbox 3.1 is causing a problem on already well-behaved 3.0 on the same machine and environment. So I think that putting all bugs regarding AMD-V not working on Virtualbox 3.1 but working well on 3.0 series is a mistake and that it should be 2 separated issues.

Virtualbox 3.1 is causing problems on my machine, not Bios and kvm etc, since with 3.0 everything works fine.. So Separate bug is needed, not this one.

You are mistaken. 3.0 contains a bug that works around BIOS issues.

There are two issues of which one is related to VirtualBox:

• KVM still claims VT-x and AMD-V for itself even when it's not using either -> KVM problem; we can't fix their unwillingness (for many years now) to coexist with other software
• BIOS incorrectly sets EFER.SVME which makes VirtualBox think somebody else is using AMD-V

I'm still unsure how many people are really affected by these BIOS bugs as we have a dozen different AMD boxes of which *none* exhibits this problem.

I'm willing to add an override option (disabled by default) for those still affected. That's the best we can offer.

I'm willing to add an override option (disabled by default) for those still affected. That's the best we can offer.

That would be greatly appreciated. Seems I fall into the BIOs camp (seeing as I don't even have KVM installed on my system) and have to downgrade to 3.0.x as the only way to be able to take advantage of AMD-V

I have the same problem. HP Compaq 6715b, AMD Turion, Windows 7. BIOS upgrade is not possible, because I use the oldest one. When this override option will be available? Should I downgrade to 3.0.x or wait for an upgrade? Thx, Barna

we can't fix their unwillingness to coexist

Seems like it was known problem with KVM prior to releasing. It is nice to coexist.

I am glad about that override option that existed in 3.0. Using Vbox from before 2.x on same machine and installation (Ubuntu LTS) and had no problems with vbox/kvm coexisting, till 3.1. That override option is appreciated and would be nice to stay selected after update, if user selected it.

Markor: Could you please stop arguing? You don't understand the problem and repeated explanations don't appear to help. There has never been an override option in 3.0 or any other version.

I think you explained problem and i do understand.. Pre-3.1 worked and override is needed for 3.1 and newer. Seems like 3.1 changed its behavior for a reason, as you explained why. sandervl73, you tried to close this bug several times, seems like that override option would be great. I have some new information that newest kvm versions now, fixed claiming virt.instructions when not used. (Worth checking if it is true) So override would be in place for current vbox installations to continue to coexist with installs now in use.

That good, so the override option is only needed for broken BIOSes.

Well for the future, yes. But for 3.1 to work right now on current 3.0 installations, there is need for override for problem that arises with 3.1 to coexist with KVM versions currently in use and that will be in use for some time. So override is needed for Kvm in 3.1+ to continue to work on same machines/installs/Os/kvm versions as 3.0.

I've added the following override option to SVN:

• set the VBOX_HWVIRTEX_IGNORE_SVM_IN_USE environment variable to true (set VBOX_HWVIRTEX_IGNORE_SVM_IN_USE=true)

This will tell VirtualBox to ignore VERR_SVM_IN_USE and continue to use AMD-V. Note that this is a hack and risky if you run more than one hypervisor at the same time.

AMD-V NOT WORKING YET AGAIN. With AMD-V enabled..... Windows 7 only boots to blank screen when booted from grub2 boot loader. Works fine with default mbr from Windows Install. Therefore, no multiboot. Also, VMWare works like a champ but is slower than a VirtualBox when it works.

HP Pavillion m9400f AMD Phenom 9750 Quad-Core 2.40 GHz 8.00GB Ram Windows Vista Home Premium SP1 64 Host Virtual Box 3.1.4r57640 Sata VHD 4 partitons 160GB total

Ubuntu 9.10 Windows 7 Empty NTFS Linux Swap

First of all I don't like your screaming. Then you reopened a ticket that is unrelated and provide ZERO information. If you want us to help you, you'll have to do a lot better than that. (= new ticket + VBox.log).

Hello, i would like to reopen this bug, since like previous poster, AMD-V is not working again in 3.1.14. Host is 64-bit Ubuntu 8.04 LTS (Hardy). On same machine Virtualbox 3.0 do fine, Virtualbox now in 3.1.4 complains about user needing to recompile kernel (??).

As explained previously in this bug, 3.1.4 may include workaround for Stable installations that have older kvm installed but not used. (Newer Kvm does not set VT/AMD-v usage if not used anymore.) Does virtualbox now refuse to work , even if kvm is not setting virt. instructions to use? Or there is some newly introduced way of switching Off Virtualbox from not coexisting with Kvm on current instalaltions, that i am not aware of? I expected there to be at least GUI oprion to do that, since most of users only use GUI and will simply not be able to use Virtualbox anymore even if previously used on same machine if that option is not in GUI. Also, disabling newer Vbox editions from working in already-existing environments already is resulting in Vbox usage decline as previous poster said.

Debian64bit client Vbox log, not working with 3.1.4, working with 3.0

This option is dangerous, this is why it is hidden. In may crash your Host OS, sending your computer to restart.

-Technologov

64bit guest log, not working with 3.1.4, working with 3.0

Then why its not dangerous and working in 3.0? Seems like political to me. Maybe I am wrong but most of users that use stable Linux distributions will just experience: "Not working" syndrome like explained and maybe stop using Virtualbox because of this.

Markor: There is a technical reason and the cause is broken BIOSes or others claiming AMD-V. Stop the paranoia and don't open bugs to spread FUD.

Could that change with Environment value needed to be set for Virtualbox to continue to work where Vbox 3.0 already worked, be documented somewhere? So people could continue using Vitrualbox on machine where 3.0 Worked?

Does Virtualbox now refuse to work whenever kvm module is present even if amd-v is not used nor set as used? This does not sound fixed to me. Not working when Kvm is loaded is new/old behavior of 3.1x with the same result as previously described in this bug. Other claiming Amd-v never stopped 3.0 from working. But 3.1 stopped noumerous people and forced them to switch to alternative solutions, when Vbox suddenly stopped working for them after update on stable/supported OS. This bug is not fixed yet since it behaves the sam way as before users have no Clue how to make 3.1 work now when upgrading form 3.0 and you know it.

I just tested with: set VBOX_HWVIRTEX_IGNORE_SVM_IN_USE=true /usr/bin/VirtualBox And it behaves the same way, like that Switch does not do its job. It is Ubuntu LTS 8.04 Hardy 64-bit Amd-v machine with old kvm loaded.

That switch should fix this behavior of 3.1 as I see? But nothing is changed and 3.1.4 still does not work for me on LTS Ubuntu. Maybe I could help with providing more logs or something? I report fix not working and I think it is a good thing to reopen this bug untill it is solved .

You did it wrong. Do

killall VBoxSVC
export VBOX_HWVIRTEX_IGNORE_SVM_IN_USE=true
VirtualBox

The killall is to make sure that the VBoxSVC daemon is killed and the export statement is required to let the child instances of the new spawned VBoxSVC daemon inherit this setting.

How many more times do I have to repeat myself here before you get the point?

One more time, so please pay attention:

1. 3.0 and before had a bug that ignored the AMD-V in-use bit set by either KVM or buggy BIOSes
2. 3.1 corrected this to prevent complete system reboots when using other hypervisors at the same time (read Windows 7 XP compatibility mode or KVM for that matter)

The fact that KVM refused to work, just by being installed and not even active, with any other hypervisor for many years until Dec. last year IS NOT OUR FAULT.