From: Avi Kivity <avi@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Stefan Bader <stefan.bader@canonical.com>,
kvm@vger.kernel.org, Andy Whitcroft <apw@canonical.com>
Subject: Re: Nested kvm_intel broken on pre 3.3 hosts
Date: Wed, 01 Aug 2012 17:08:53 +0300 [thread overview]
Message-ID: <50193875.3090200@redhat.com> (raw)
In-Reply-To: <20120801133940.GB27579@redhat.com>
On 08/01/2012 04:39 PM, Gleb Natapov wrote:
> On Wed, Aug 01, 2012 at 01:29:11PM +0200, Stefan Bader wrote:
>> I have been looking at a report[1] about the kvm_intel module failing to load on
>> linux v3.3 and newer guests when running on a v3.2 host. Bisection turned up the
>> following patch:
>>
>> commit fee84b079d5ddee2247b5c1f53162c330c622902
>> Author: Avi Kivity <avi@redhat.com>
>> Date: Thu Nov 10 14:57:25 2011 +0200
>>
>> KVM: VMX: Intercept RDPMC
>>
>> Intercept RDPMC and forward it to the PMU emulation code.
>>
>> Signed-off-by: Avi Kivity <avi@redhat.com>
>> Signed-off-by: Gleb Natapov <gleb@redhat.com>
>> Signed-off-by: Avi Kivity <avi@redhat.com>
>>
>> It looks like requiring the feature based on cpu fails when the host (outer kvm
>> module) code does not support it. So maybe that should be optional instead of
>> required?
> According to Intel SDM there was never CPU that didn't support RDPMC
> exiting. Looks like unfortunate nested VMX bug.
Moreover, that same commit fixes the bug in nested vmx. So if you
update your host kernel to the same version as your L1 guest (or, at
your option, any later version) it should work.
We could backport that part of the patch, though as nested vmx is still
experimential, I don't think it's worth it.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-08-01 14:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 11:29 Nested kvm_intel broken on pre 3.3 hosts Stefan Bader
2012-08-01 13:39 ` Gleb Natapov
2012-08-01 14:08 ` Avi Kivity [this message]
2012-08-01 14:26 ` Stefan Bader
2012-08-01 14:29 ` Avi Kivity
2012-08-01 15:07 ` Nadav Har'El
2012-08-01 15:10 ` Gleb Natapov
2012-08-01 15:11 ` Avi Kivity
2012-08-02 15:19 ` Stefan Bader
2012-08-02 15:19 ` [PATCH 1/7] KVM: Move cpuid code to new file Stefan Bader
2012-08-02 15:19 ` [PATCH 2/7] KVM: expose latest Intel cpu new features (BMI1/BMI2/FMA/AVX2) to guest Stefan Bader
2012-08-02 15:19 ` [PATCH 3/7] KVM: Expose kvm_lapic_local_deliver() Stefan Bader
2012-08-02 15:19 ` [PATCH 4/7] KVM: Expose a version 2 architectural PMU to a guests Stefan Bader
2012-08-02 15:19 ` [PATCH 5/7] KVM: Add generic RDPMC support Stefan Bader
2012-08-02 15:19 ` [PATCH 6/7] KVM: SVM: Intercept RDPMC Stefan Bader
2012-08-02 15:19 ` [PATCH 7/7] KVM: VMX: " Stefan Bader
2012-08-02 15:26 ` Nested kvm_intel broken on pre 3.3 hosts Avi Kivity
2012-08-03 10:55 ` (unknown), Stefan Bader
2012-08-03 10:57 ` Nested kvm_intel broken on pre 3.3 hosts Stefan Bader
2012-08-05 9:18 ` Avi Kivity
2012-08-06 14:40 ` Stefan Bader
2012-08-09 7:13 ` Stefan Bader
2012-08-09 9:34 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50193875.3090200@redhat.com \
--to=avi@redhat.com \
--cc=apw@canonical.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=stefan.bader@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).