Mailinglist Archive: opensuse-bugs (13048 mails)

< Previous Next >
[Bug 460042] [Virtualization:KVM] kernel: kvm: enabling virtualization on CPU1 failed
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Sun, 4 Jan 2009 12:31:05 -0700 (MST)
  • Message-id: <20090104193105.8CDA6CC7D3@xxxxxxxxxxxxxxxxxxxxxx>

User novellbmw@xxxxxxxx added comment

--- Comment #8 from Bernhard Wiedemann <novellbmw@xxxxxxxx> 2009-01-04
12:30:52 MST ---
I did quite some extra testing with this KVM/VirtualBox interaction now.

Is the VirtualBox VM still running when you start the KVM VM?
no, after the VirtualBox VM was running and stopped, KVM still failed with that
"busy" error.

Could you please try to build a vanilla KVM version from
and see if modprob'ing that fails after you used VirtualBox?
I used the kvm-78.tar.bz2 from the source RPM and interestingly kvm.ko and
kvm-amd.ko did insmod just fine after using VirtualBox.
What is even more interesting is that with this vanilla kvm module, qemu-kvm
started working again which can easily be explained by the lacking check of the
MSR_EFER_SVME_MASK bit (I looked at the source).
However (on a sidenote), I also noticed a
"kernel BUG at /home/bernhard/code/rpm/kvm/kvm-78/kernel/x86/kvm_main.c:1853!"
in that vanilla kvm-78 when I tested its behaviour with both qemu-kvm and
VirtualBox using SVM at the same time. This was folled by a complete panic on
rmmod kvm

Finally, I added two printk lines to the opensuse-patched kvm-78/svm.c:313 ++

in the good case (before starting VirtualBox), dmesg has
loaded kvm module (kvm-78)
smp id=2 efer is d01
smp id=1 efer is d01
smp id=3 efer is d01
smp id=0 efer is d01

In the bad case (after starting and stopping VirtualBox)
smp id=2 efer is 1d01
smp id=1 efer is 1d01
smp id=3 efer is 1d01
svm busy
svm busy
kvm: enabling virtualization on CPU1 failed
kvm: enabling virtualization on CPU3 failed
svm busy
kvm: enabling virtualization on CPU2 failed

Which clearly shows bit 12 set to 1 which means VirtualBox/vboxdrv is setting
the EFER.SVME bit without need and not clearing it after use and not even on

Another interesting point is that when I activate AMD-V on my VirtualBox VM and
start it and stop it, then the EFER.SVME bit is properly cleared, so that
qemu-kvm just works again.

To make sure that this issue has not been addressed by SUN in the meantime or
was specific to the PUEL version, I also reproduced the very same behaviour
with current VirtualBox-2.1.1-OSE-svn
It properly releases SVME after using it for a VM, but it erroneously blocks
SVME while and after _not_ using it in a VM without hardware-virtualisation.
So it appears to me to be a bug in VirtualBox, while opensuse's KVM just does
the right thing under these circumstances.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >