Re: Nested kvm_intel broken on pre 3.3 hosts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux