From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH 1/2] vmx,svm: Add module parameter to ignore the 'in use' check Date: Tue, 05 Jul 2011 14:07:19 +0300 Message-ID: <1309864039.4117.57.camel@sasha> References: <1309820954-8629-1-git-send-email-levinsasha928@gmail.com> <4E12C6A1.70105@redhat.com> <1309853683.4117.33.camel@sasha> <20110705091106.GK29299@8bytes.org> <1309858322.4117.36.camel@sasha> <4E12DB73.9040601@redhat.com> <1309859802.4117.44.camel@sasha> <4E12E951.3040304@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Joerg Roedel , kvm@vger.kernel.org, Marcelo Tosatti To: Avi Kivity Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:41549 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932066Ab1GELH1 (ORCPT ); Tue, 5 Jul 2011 07:07:27 -0400 Received: by wyg8 with SMTP id 8so3905281wyg.19 for ; Tue, 05 Jul 2011 04:07:26 -0700 (PDT) In-Reply-To: <4E12E951.3040304@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, 2011-07-05 at 13:37 +0300, Avi Kivity wrote: > On 07/05/2011 12:56 PM, Sasha Levin wrote: > > Please note that I don't have access to the hardware in question, this > > was done over IRC. > > > > I understand that. Can you get in contact with the reporter again? > Hopefully, If he comes back on IRC (or reads these mails :) ). > > Here are the steps taken in debugging this issue: > > > > 1. Looking at the dmesg ( http://pastebin.com/eM7bDY8r ) we saw that > > when trying to load the kvm module, the following error shows up: 'kvm: > > enabling virtualization on CPU0 failed'. > > > > 2. We went through the lsmod output (unfortunately I don't have the link > > as it's gone from my IRC buffer) and didn't see any modules belonging to > > other hypervisors. > > > > 3. At that point, looking at the code - we figured that a set SVM flag > > is the possible culprit since it's the only code path which fails > > loading the module with that error message without printing anything > > else. > > > > 4. Installed msr-tools and injected the msr module so that we could read > > msr values from userspace. > > > > 5. Ran 'rdmsr 0xc0000080' to read the extended feature register. The > > output had bit 12 set - which means that SVM bit was enabled. > > > > 6. Ran 'wrmsr 0xc0000080 0xd01' which disabled the SVM bit. > > > > 7. kvm module loaded ok. > > My questions are: > > - was a BIOS update attempted? at least VMware uses the same check as > kvm, and probably virtualbox as well, so this problem should have been > seen before. We didn't update the BIOS. virtualbox was installed previously and didn't work properly either - thats why he tried kvm afaik. We made sure to remove virtualbox properly and did a reset afterwards. After removal, no virtualbox modules were loaded at any point. > - was the vendor contacted? Not that I think we'll see a lot of good > from that. Nope. > - was this after a reset or cold boot? This was a reset, we didn't try a cold boot. > - maybe a stealth rootkit is involved? > A rootkit that messed up the MSRs or runs a hidden guest sounds like a possibility too. Alexander Graf suggested it's a simple case of a BIOS vendor not implementing specs properly as he has seen a similar case of BIOS only allowing to start virtualization on the first CPU. -- Sasha.