From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Nested kvm_intel broken on pre 3.3 hosts Date: Thu, 09 Aug 2012 09:13:45 +0200 Message-ID: <50236329.2040509@canonical.com> References: <501A9C3D.9080602@redhat.com> <1343991434-8241-1-git-send-email-stefan.bader@canonical.com> <501E3A55.9080002@redhat.com> <501FD759.8030104@canonical.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB21046412A0C09F1F2C5F7E6" Cc: nyh@math.technion.ac.il, Gleb Natapov , Andy Whitcroft , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from youngberry.canonical.com ([91.189.89.112]:36626 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755516Ab2HIHOC (ORCPT ); Thu, 9 Aug 2012 03:14:02 -0400 In-Reply-To: <501FD759.8030104@canonical.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB21046412A0C09F1F2C5F7E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06.08.2012 16:40, Stefan Bader wrote: > 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 200= 1 >>> From: Stefan Bader >>> 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 >>> --- >>> 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(v= oid) >>> #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; >>> } >>> =20 >>> +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 kv= m_vcpu *vcpu) =3D { >>> [EXIT_REASON_HLT] =3D handle_halt, >>> [EXIT_REASON_INVD] =3D handle_invd, >>> [EXIT_REASON_INVLPG] =3D handle_invlpg, >>> + [EXIT_REASON_RDPMC] =3D handle_rdpmc, >>> [EXIT_REASON_VMCALL] =3D handle_vmcall, >>> [EXIT_REASON_VMCLEAR] =3D handle_vmclear, >>> [EXIT_REASON_VMLAUNCH] =3D handle_vmlaunch, >>> >> >> Provided you backport the bit in nested_vmx_exit_handled(). That take= s >> the L2->L1 RDPMC exit and forwards it to L1. >> > The nested_vmx_exit_handled handled function is already there (in 3.1).= >=20 > commit 644d711aa0e16111d8aba6d289caebec013e26ea > Author: Nadav Har'El > Date: Wed May 25 23:12:35 2011 +0300 >=20 > KVM: nVMX: Deciding if L0 or L1 should handle an L2 exit >=20 > 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). >=20 > 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. >=20 Avi, was the last version of the patch (only adding the flag to the neste= d MSRs) good for submitting to stable from your point of view? (inlining though this will be broken) =46rom b79a5f03b4d9a1a56949d6ef38fd4879ff1b8aee Mon Sep 17 00:00:00 2001 From: Stefan Bader 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 --- 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 --------------enigB21046412A0C09F1F2C5F7E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJQI2MyAAoJEOhnXe7L7s6j1foP/3vNv1XPigxktV8tKbxsc51Z po0VF6INyECUrTVAnGTY8M6QA9fr1xDCc19hksKt5NRlvjVV5LFUf+ZCm2xvts+S X6bV2GXbeLpV8xT1rV2yovZY/2/cZvYkvbnGMxEIRuMaOrTWnh7DnCP0YdnvzqQJ NqiWav4rcSUOUPCF2OQ0nUXt/2eVR8hR2tJPDWat7ECCuwaq5Rt4vi6amZ88cZ0/ ZAxD4ROh75SqqTMng5rYpGqHttSIbKJU9E2qxYZAByl6WtQkAOxkWWAlyoLFta96 nWCB8HBaXEIGC8EEfC4XGEh+qqxlZGFf6RP4OjNLsutFvLoQ7iTEYfmWWt1n5J/o gZLswSRYPcerx8cAY7LroervdFs6k6Rv4jMpZxnp6o3ry93USXqXn8/kVhCDkxiC YuzwICOgMD44Jttwm7L05kAA6e+NTtULBPVyxRP0VMRANzFhZ+0AvndUGfPCuNv9 i6w+VN5HIF1ZI8FUHcnLUfvs5sZ+wqNxoQrLGEe0hkwPK1pBmiPGgKBahckzNgFI xlQYf0yco6rd+BSM5Cp/zYBE7FgtUZRv74k8JjVo9Z3AR8SQpl98yISlOojX2oVk ungyjlqG9IX7oyLZnJQ1CT17VDgvXaXYq2a8D0G55elv0FpT5CAaf5EV4poX9TfC vCte3SI9otlaFy12iiYY =A9EI -----END PGP SIGNATURE----- --------------enigB21046412A0C09F1F2C5F7E6--