From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932952AbbCRJ72 (ORCPT ); Wed, 18 Mar 2015 05:59:28 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:34593 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755177AbbCRJ7Z (ORCPT ); Wed, 18 Mar 2015 05:59:25 -0400 Message-ID: <55094C73.4000608@canonical.com> Date: Wed, 18 Mar 2015 10:59:15 +0100 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Paolo Bonzini , kvm@vger.kernel.org, Linux Kernel Mailing List Subject: Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.15 References: <55093B52.5090904@canonical.com> <550942ED.4040809@redhat.com> In-Reply-To: <550942ED.4040809@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1AArJhfrlrTjds5R1eO6XK48ocDBkEkWx" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1AArJhfrlrTjds5R1eO6XK48ocDBkEkWx Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 18.03.2015 10:18, Paolo Bonzini wrote: >=20 >=20 > On 18/03/2015 09:46, Stefan Bader wrote: >> >> Regardless of that, I wonder whether the below (this version untested)= sound >> acceptable for upstream? At least it would make debugging much simpler= =2E :) >> >> --- a/arch/x86/kvm/vmx.c >> +++ b/arch/x86/kvm/vmx.c >> @@ -2953,8 +2953,11 @@ static __init int adjust_vmx_controls(u32 ctl_m= in, u32 ct >> ctl |=3D vmx_msr_low; /* bit =3D=3D 1 in low word =3D=3D> mu= st be one */ >> >> /* Ensure minimum (required) set of control bits are supported= =2E */ >> - if (ctl_min & ~ctl) >> + if (ctl_min & ~ctl) { >> + printk(KERN_ERR "vmx: msr(%08x) does not match require= ments. " >> + "req=3D%08x cur=3D%08x\n", msr, ctl_mi= n, ctl); >> return -EIO; >> + } >> >> *result =3D ctl; >> return 0; >=20 > Yes, this is nice. Maybe -ENODEV. Maybe, though I did not change that. Just added to give some kind of hint= when the module would otherwise fail with just an IO error. >=20 > Also, a minimal patch for Ubuntu would probably be: >=20 > @@ -2850,7 +2851,7 @@ static __init int setup_vmcs_config(struct vmcs_c= onfig *vmcs_conf) > vmx_capability.ept, vmx_capability.vpid); > } > =20 > - min =3D 0; > + min =3D VM_EXIT_SAVE_DEBUG_CONTROLS; > #ifdef CONFIG_X86_64 > min |=3D VM_EXIT_HOST_ADDR_SPACE_SIZE; > #endif >=20 > but I don't think it's a good idea to add it to stable kernels. Why is that? Because it has a risk of causing the module failing to load = on L0 where it did work before? Which would be something I would rather avoid. Generally I think it would be good to have something that can be generall= y applied. Given the speed that cloud service providers tend to move forwar= d (ok they may not actively push the ability to go nested). -Stefan >=20 > Paolo >=20 --1AArJhfrlrTjds5R1eO6XK48ocDBkEkWx 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 iQIcBAEBCgAGBQJVCUx5AAoJEOhnXe7L7s6jO7EP/j9J8wWRktElHqv34CfMapV+ Pg44NPMW7Vvc5B8xs0xA0WaNPTqYF4rLjJjwYeeiMEdlKEFcwiYOhGmiy+sba34P xUEyJVDL3iYTY2JxQQCl0Idjq7mhvyAoFpwIWHOCzlprw7prnZAQVKCUxsGLUdsc qED44EX/LDxcwFAuHz+allVSEOpuIE9IHl60IX9Tf2kQXswtt0JH/Rh5GL45S13s X2Hn1o4utEqfGF9W2nOtDaMUq3eSDpTO7nTLVjz0Xt2HRPif3D7vSIJc3YcA9Zxr 2ObKalkd+XYmHc0yyyfjGjo30G5MPRW4UU1wQXyrNMkMv/p8BJA0yFwwquDzfaIJ CwFpI3EqNKzFmefHrexARlErWQ+4Gxjhmy/4TaJt6eb6BF4MeJOc12a/okdr2x0D Z6r6e9xeNLD2KRRy4azwAaOCWovzdnhBnx8f/LiyCojuj0YTpVohW+nCexIM+Q4j a866s2cSBR9sclUL5PNLZSChbR/7dGz3TB1K92LfICnmPDAyg4jcRRCkefjG3Hpo P3gcAOOObn9qU8nLL6FQJkBb7+7RPidqviyt/zmwNhrUFdVh0W6+FtssVujuyZ7i Z4rjvn54MTKAVZpN+SCTZbafkL77RPLH/XM6vvgW669Rtfq9YtUbpaU9llrwO1Ib CgJNvTEf4RLkL0R/6Sml =sZd9 -----END PGP SIGNATURE----- --1AArJhfrlrTjds5R1eO6XK48ocDBkEkWx--