kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Bader <stefan.bader@canonical.com>
To: Avi Kivity <avi@redhat.com>
Cc: nyh@math.technion.ac.il, Gleb Natapov <gleb@redhat.com>,
	Andy Whitcroft <apw@canonical.com>,
	kvm@vger.kernel.org
Subject: Re: Nested kvm_intel broken on pre 3.3 hosts
Date: Mon, 06 Aug 2012 16:40:25 +0200	[thread overview]
Message-ID: <501FD759.8030104@canonical.com> (raw)
In-Reply-To: <501E3A55.9080002@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 3709 bytes --]

On 05.08.2012 11:18, Avi Kivity wrote:
> On 08/03/2012 01:57 PM, Stefan Bader wrote:
>>> No, you're backporting the entire feature.  All we need is to expose
>>> RDPMC intercept to the guest.
>>
>> Oh well, I thought that was the thing you asked for...
> 
> Sorry for being unclear.
> 
>>
>>> It should be sufficient to backport the bits in
>>> nested_vmx_setup_ctls_msrs() and nested_vmx_exit_handled().
>>
>> Ok, how about that? It is probably wrong again, but at least it
>> allows to load the kvm-intel module from within a nested guest
>> and not having the feature pretend to fail seems the closest
>> thing to do...
>>
>> ---
>>
>> From 0aeb99348363b7aeb2b0bd92428cb212159fa468 Mon Sep 17 00:00:00 2001
>> From: Stefan Bader <stefan.bader@canonical.com>
>> Date: Thu, 10 Nov 2011 14:57:25 +0200
>> Subject: [PATCH] KVM: VMX: Fake intercept RDPMC
>>
>> Based on commit fee84b079d5ddee2247b5c1f53162c330c622902 upstream.
>>
>>   Intercept RDPMC and forward it to the PMU emulation code.
>>
>> But drop the requirement for the feature being present and instead
>> of forwarding, cause a GP as if the call had failed.
>>
>> BugLink: http://bugs.launchpad.net/bugs/1031090
>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
>> ---
>>  arch/x86/kvm/vmx.c |   10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 7315488..fc937f2 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -1956,6 +1956,7 @@ static __init void nested_vmx_setup_ctls_msrs(void)
>>  #endif
>>  		CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING |
>>  		CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING |
>> +		CPU_BASED_RDPMC_EXITING |
>>  		CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
>>  	/*
>>  	 * We can allow some features even when not supported by the
>> @@ -4613,6 +4614,14 @@ static int handle_invlpg(struct kvm_vcpu *vcpu)
>>  	return 1;
>>  }
>>  
>> +static int handle_rdpmc(struct kvm_vcpu *vcpu)
>> +{
>> +	/* Instead of implementing the feature, cause a GP */
>> +	kvm_complete_insn_gp(vcpu, 1);
>> +
>> +	return 1;
>> +}
> 
> In fact this should never be called, since we never request RDPMC
> exiting for L1.
> 
>> +
>>  static int handle_wbinvd(struct kvm_vcpu *vcpu)
>>  {
>>  	skip_emulated_instruction(vcpu);
>> @@ -5563,6 +5572,7 @@ static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = {
>>  	[EXIT_REASON_HLT]                     = handle_halt,
>>  	[EXIT_REASON_INVD]		      = handle_invd,
>>  	[EXIT_REASON_INVLPG]		      = handle_invlpg,
>> +	[EXIT_REASON_RDPMC]                   = handle_rdpmc,
>>  	[EXIT_REASON_VMCALL]                  = handle_vmcall,
>>  	[EXIT_REASON_VMCLEAR]	              = handle_vmclear,
>>  	[EXIT_REASON_VMLAUNCH]                = handle_vmlaunch,
>>
> 
> Provided you backport the bit in nested_vmx_exit_handled().  That takes
> the L2->L1 RDPMC exit and forwards it to L1.
> 
The nested_vmx_exit_handled handled function is already there (in 3.1).

commit 644d711aa0e16111d8aba6d289caebec013e26ea
Author: Nadav Har'El <nyh@il.ibm.com>
Date:   Wed May 25 23:12:35 2011 +0300

    KVM: nVMX: Deciding if L0 or L1 should handle an L2 exit

Though I checked what happens if I drop anything beside the change in
nested_vmx_setup_ctls_msrs. If running "perf test" (which does some
RDPMC test) is sufficient to prove things are ok, then it seems to be
good enough. That test fails already on the perf_event_open syscall
(returning -ENOENT).

So this remaining (attached patch) change would be enough to allow
the kvm_intel module get loaded from newer kernels on an 3.2 host.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-KVM-VMX-Set-CPU_BASED_RDPMC_EXITING-for-nested.patch --]
[-- Type: text/x-diff; name="0001-KVM-VMX-Set-CPU_BASED_RDPMC_EXITING-for-nested.patch", Size: 1220 bytes --]

From b79a5f03b4d9a1a56949d6ef38fd4879ff1b8aee Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Thu, 10 Nov 2011 14:57:25 +0200
Subject: [PATCH] KVM: VMX: Set CPU_BASED_RDPMC_EXITING for nested

Based on commit fee84b079d5ddee2247b5c1f53162c330c622902 upstream.

  Intercept RDPMC and forward it to the PMU emulation code.

Newer vmx support will only allow to load the kvm_intel module
if RDPMC_EXITING is supported. Even without the actual support
this part of the change is required on 3.2 hosts.

BugLink: http://bugs.launchpad.net/bugs/1031090
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 arch/x86/kvm/vmx.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 114fe29..94e6749 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1957,6 +1957,7 @@ static __init void nested_vmx_setup_ctls_msrs(void)
 #endif
 		CPU_BASED_MOV_DR_EXITING | CPU_BASED_UNCOND_IO_EXITING |
 		CPU_BASED_USE_IO_BITMAPS | CPU_BASED_MONITOR_EXITING |
+		CPU_BASED_RDPMC_EXITING |
 		CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
 	/*
 	 * We can allow some features even when not supported by the
-- 
1.7.9.5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

  reply	other threads:[~2012-08-06 14:40 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
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 [this message]
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=501FD759.8030104@canonical.com \
    --to=stefan.bader@canonical.com \
    --cc=apw@canonical.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=nyh@math.technion.ac.il \
    /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).