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: Mon, 06 Aug 2012 16:40:25 +0200 Message-ID: <501FD759.8030104@canonical.com> References: <501A9C3D.9080602@redhat.com> <1343991434-8241-1-git-send-email-stefan.bader@canonical.com> <501E3A55.9080002@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3750CA7B82E18C805E3255B1" 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]:51142 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754558Ab2HFOkc (ORCPT ); Mon, 6 Aug 2012 10:40:32 -0400 In-Reply-To: <501E3A55.9080002@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3750CA7B82E18C805E3255B1 Content-Type: multipart/mixed; boundary="------------050206090101060402000004" This is a multi-part message in MIME format. --------------050206090101060402000004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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... >=20 > Sorry for being unclear. >=20 >> >>> 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 >> 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(vo= id) >> #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; >> +} >=20 > In fact this should never be called, since we never request RDPMC > exiting for L1. >=20 >> + >> 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) =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, >> >=20 > Provided you backport the bit in nested_vmx_exit_handled(). That takes= > the L2->L1 RDPMC exit and forwards it to L1. >=20 The nested_vmx_exit_handled handled function is already there (in 3.1). commit 644d711aa0e16111d8aba6d289caebec013e26ea Author: Nadav Har'El 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. --------------050206090101060402000004 Content-Type: text/x-diff; name="0001-KVM-VMX-Set-CPU_BASED_RDPMC_EXITING-for-nested.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="0001-KVM-VMX-Set-CPU_BASED_RDPMC_EXITING-for-nested.patch" =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 --=20 1.7.9.5 --------------050206090101060402000004-- --------------enig3750CA7B82E18C805E3255B1 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/ iQIcBAEBCgAGBQJQH9dZAAoJEOhnXe7L7s6jNJ4QAJvt6PEcvTzNg/87Pyi/YTIP ZUasOMbD5MbVioXJUulQ+eE4mMxtb+wFyNkhhcwACq0TL3yqDN4QSe2HH2JSD1Z7 69yo2QLDTqxPD0h2ndtFtsjxG9Dw9/af8lOs29yKXpyivFC+GprDrGfKtBHXxXWX 4NmiFHSZVZdDovh1GwBVjrI2QgijS0LHt/YLVMZCg9TVpNRqtml3DwlKE2qjL4IG PCDc3zvsUQGaIxohN5HCAZUqf0xDRdo5YGFSIAWZOGqYpMGF4F0iqx4+Zjs1Kxx8 7fMStNEqRNncA8QqQTaHRnIECFolfuTnpI2drroe5DPkbZAv8ll/b/eG5z8f9dM2 hut3mzwq8hOLcVGzgP2BZ4R5wOXboJIFDZ4TtDgcVZMd4GPd39/N/mjY2+azvz/V gIAiIrvcrZdcZiYFx9/MVON0tphLx903HuFi2mZgYGbrVmGev2jdSH9tlldOVzGF uZ3Zj0gvsRQC0r3BAs8CSRZSw7yEbPrcGTnQP5QDSkP8SQRZw/ddpwR10ZoJE4vW 0RN2pZJ1ATcwLggb7CMOd2IM/jGwHLVGNED4Jh/jbCVZ4L5w7gPURgMKuD7D9hk3 5+8VFFxerXMwaY9Z+yL1PudTciU1A6lTw/GC/QbBQUGmSocY2K5ZooB+xdLg0EQD NNAe5Vpplu+E6EvyDGu0 =CVYm -----END PGP SIGNATURE----- --------------enig3750CA7B82E18C805E3255B1--