VirtualBox

Opened 14 years ago

Last modified 8 months ago

#5639 closed defect

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

Reported by: palomino Owned by:
Component: VMM/HWACCM Version: VirtualBox 3.1.0
Keywords: AMD-V Cc:
Guest type: Windows Host type: Linux

Description (last modified by Sander van Leeuwen)

Cpu: AMD AthlonIIx3 425. Motherboard: GA-MA78GM-US2H HostOS: Ubuntu 9.10 GuestOS: Windows 2003 (2 processors allocated) Virtualization is enabled in BIOS.

When i upgraded to 3.1.0, it reported "VT-x is not available. (VERR_VMX_NO_VMX)." when i tried to start the guest os. 3.0.12 worked fine. Reinstall 3.1.0 can not fix the issue. Remove 3.1.0 -> install 3.0.12 -> remove 3.0.12 -> install 3.1.0 works. But if I restart the computer, I have to do that again. BTW: It did not happen on another computer with intel's cpu.

Recommendations:

- upgrade your BIOS if possible
- remove the KVM modules (Linux host)

3.1.4 will contain a workaround for people with a broken BIOS and no option to update it.

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 dangerous if you run more than one hypervisor at the same time. USE AT YOUR OWN RISK.

Change History (62)

by palomino, 14 years ago

Attachment: VBox.log added

comment:1 by Frank Mehnert, 14 years ago

Summary: AMD-V not workingAMD-V not working: VERR_SVM_IN_USE

by Ross Jenkins, 14 years ago

VBox 3.1.0 log after unsuccessful attempt to open 64 bit guest

comment:2 by Ross Jenkins, 14 years ago

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).

comment:3 by Sander van Leeuwen, 14 years ago

Resolution: worksforme
Status: newclosed

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

comment:4 by Steve Wark, 14 years ago

Resolution: worksforme
Status: closedreopened

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.

by Steve Wark, 14 years ago

Attachment: logs_3.0.12_3.1.0.zip added

Logs for 3.1.0 failure and 3.0.12 success

comment:5 by Sander van Leeuwen, 14 years ago

Resolution: worksforme
Status: reopenedclosed

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.

comment:6 by Technologov, 14 years ago

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

comment:7 by Sander van Leeuwen, 14 years ago

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

comment:8 by Steve Wark, 14 years ago

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.

comment:9 by Sander van Leeuwen, 14 years ago

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.

comment:10 by Technologov, 14 years ago

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 ?

comment:11 by Technologov, 14 years ago

Resolution: worksforme
Status: closedreopened

comment:12 by Ross Jenkins, 14 years ago

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.

comment:13 by Sander van Leeuwen, 14 years ago

Resolution: worksforme
Status: reopenedclosed
Summary: AMD-V not working: VERR_SVM_IN_USEAMD-V not working: VERR_SVM_IN_USE -> update your BIOS

Great. Thanks for the feedback.

comment:14 by Steve Wark, 14 years ago

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.

comment:15 by Steve Wark, 14 years ago

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.

comment:16 by Igor M Podlesny, 14 years ago

Resolution: worksforme
Status: closedreopened
  • 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?

comment:17 by Technologov, 14 years ago

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

comment:18 by initzero, 14 years ago

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)

comment:19 by akukalle, 14 years ago

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

in reply to:  19 comment:20 by akukalle, 14 years ago

Replying to akukalle:

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

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

comment:21 by wmeissner, 14 years ago

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.

comment:22 by darkjavi, 14 years ago

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)

comment:23 by Krzysztof, 14 years ago

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.

comment:24 by Sander van Leeuwen, 14 years ago

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

comment:25 by Technologov, 14 years ago

Actually, some Atoms _do_ support VT-x.

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

-Technologov

comment:26 by Krzysztof, 14 years ago

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

comment:27 by Hugo van der Wijst, 14 years ago

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.

comment:28 by Igor M Podlesny, 14 years ago

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

in reply to:  28 ; comment:29 by Jaromir Obr, 14 years ago

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.

comment:30 by Hugo van der Wijst, 14 years ago

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

in reply to:  29 ; comment:31 by Hugo van der Wijst, 14 years ago

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?

in reply to:  31 comment:32 by initzero, 14 years ago

-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.

comment:33 by initzero, 14 years ago

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

Would this work? ;-)

comment:34 by AgentE382, 14 years ago

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

comment:35 by Keyzer Suze, 14 years ago

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 :)

in reply to:  33 comment:36 by Hugo van der Wijst, 14 years ago

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.

comment:37 by Keyzer Suze, 14 years ago

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

comment:38 by Ian MacDonald, 14 years ago

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.

comment:39 by Ian MacDonald, 14 years ago

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?

comment:40 by Ian MacDonald, 14 years ago

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

comment:41 by Marko O., 14 years ago

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.

comment:42 by Marko O., 14 years ago

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

in reply to:  42 comment:43 by mankiko, 14 years ago

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

comment:44 by hyjgadjhgasdc, 14 years ago

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....

comment:45 by Ian MacDonald, 14 years ago

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

comment:46 by mankiko, 14 years ago

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

in reply to:  46 comment:47 by Hugo van der Wijst, 14 years ago

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.

comment:48 by Marko O., 14 years ago

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.

comment:49 by Sander van Leeuwen, 14 years ago

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.

in reply to:  49 comment:50 by mankiko, 14 years ago

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

comment:51 by Gőgös Barnabás, 14 years ago

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

in reply to:  51 comment:52 by Marko O., 14 years ago

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.

comment:53 by Sander van Leeuwen, 14 years ago

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.

comment:54 by Marko O., 14 years ago

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.

comment:55 by Sander van Leeuwen, 14 years ago

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

comment:56 by Marko O., 14 years ago

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.

comment:57 by Sander van Leeuwen, 14 years ago

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

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.

comment:58 by Sander van Leeuwen, 14 years ago

Description: modified (diff)

comment:59 by Sander van Leeuwen, 14 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use