From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v7 01/15] nEPT: Support LOAD_IA32_EFER entry/exit controls for L1 Date: Tue, 06 Aug 2013 10:18:17 +0200 Message-ID: <5200B149.80601@web.de> References: <1375690040-5764-1-git-send-email-gleb@redhat.com> <1375690040-5764-2-git-send-email-gleb@redhat.com> <20130805114032.GE10891@redhat.com> <5200AA0B.5080409@web.de> <20130806075109.GA8218@redhat.com> <5200ABDD.5050307@web.de> <20130806080051.GB8218@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cqU7Pv0Gx6fEDb6rBgObgNuGopd0DrNmR" Cc: Arthur Chunqi Li , kvm , Xiao Guangrong , Jun Nakajima , Yang Zhang , Paolo Bonzini To: Gleb Natapov Return-path: Received: from mout.web.de ([212.227.15.3]:54800 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754299Ab3HFISV (ORCPT ); Tue, 6 Aug 2013 04:18:21 -0400 Received: from mchn199C.mchp.siemens.de ([95.157.58.223]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MbQLE-1VPOJD0LC8-00Ioc4 for ; Tue, 06 Aug 2013 10:18:20 +0200 In-Reply-To: <20130806080051.GB8218@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cqU7Pv0Gx6fEDb6rBgObgNuGopd0DrNmR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-08-06 10:00, Gleb Natapov wrote: > On Tue, Aug 06, 2013 at 09:55:09AM +0200, Jan Kiszka wrote: >> On 2013-08-06 09:51, Gleb Natapov wrote: >>> On Tue, Aug 06, 2013 at 09:47:23AM +0200, Jan Kiszka wrote: >>>> On 2013-08-05 13:40, Gleb Natapov wrote: >>>>> On Mon, Aug 05, 2013 at 07:27:33PM +0800, Arthur Chunqi Li wrote: >>>>>> On Mon, Aug 5, 2013 at 4:07 PM, Gleb Natapov wro= te: >>>>>>> From: Nadav Har'El >>>>>>> >>>>>>> Recent KVM, since http://kerneltrap.org/mailarchive/linux-kvm/201= 0/5/2/6261577 >>>>>>> switch the EFER MSR when EPT is used and the host and guest have = different >>>>>>> NX bits. So if we add support for nested EPT (L1 guest using EPT = to run L2) >>>>>>> and want to be able to run recent KVM as L1, we need to allow L1 = to use this >>>>>>> EFER switching feature. >>>>>>> >>>>>>> To do this EFER switching, KVM uses VM_ENTRY/EXIT_LOAD_IA32_EFER = if available, >>>>>>> and if it isn't, it uses the generic VM_ENTRY/EXIT_MSR_LOAD. This= patch adds >>>>>>> support for the former (the latter is still unsupported). >>>>>>> >>>>>>> Nested entry and exit emulation (prepare_vmcs_02 and load_vmcs12_= host_state, >>>>>>> respectively) already handled VM_ENTRY/EXIT_LOAD_IA32_EFER correc= tly. So all >>>>>>> that's left to do in this patch is to properly advertise this fea= ture to L1. >>>>>>> >>>>>>> Note that vmcs12's VM_ENTRY/EXIT_LOAD_IA32_EFER are emulated by L= 0, by using >>>>>>> vmx_set_efer (which itself sets one of several vmcs02 fields), so= we always >>>>>>> support this feature, regardless of whether the host supports it.= >>>>>>> >>>>>>> Reviewed-by: Orit Wasserman >>>>>>> Signed-off-by: Nadav Har'El >>>>>>> Signed-off-by: Jun Nakajima >>>>>>> Signed-off-by: Xinhao Xu >>>>>>> Signed-off-by: Yang Zhang >>>>>>> Signed-off-by: Gleb Natapov >>>>>>> --- >>>>>>> arch/x86/kvm/vmx.c | 23 ++++++++++++++++------- >>>>>>> 1 file changed, 16 insertions(+), 7 deletions(-) >>>>>>> >>>>>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >>>>>>> index e999dc7..27efa6a 100644 >>>>>>> --- a/arch/x86/kvm/vmx.c >>>>>>> +++ b/arch/x86/kvm/vmx.c >>>>>>> @@ -2198,7 +2198,8 @@ static __init void nested_vmx_setup_ctls_ms= rs(void) >>>>>>> #else >>>>>>> nested_vmx_exit_ctls_high =3D 0; >>>>>>> #endif >>>>>>> - nested_vmx_exit_ctls_high |=3D VM_EXIT_ALWAYSON_WITHOUT_T= RUE_MSR; >>>>>>> + nested_vmx_exit_ctls_high |=3D (VM_EXIT_ALWAYSON_WITHOUT_= TRUE_MSR | >>>>>>> + VM_EXIT_LOAD_IA32_EFER); >>>>>> Gleb, why we don't need to check whether host supports >>>>>> VM_EXIT_LOAD_IA32_EFER here, as what you noted in my >>>>>> VM_EXIT_LOAD_IA32_PAT patch? >>>>> Nested VMX completely emulates the capability. >>>> >>>> No, it doesn't. The values for host/guest are handled over via the >>>> corresponding VMCS fields, physically, even though the actual loadin= g is >>>> emulated then. So we must not expose this feature unconditionally. >>> Can you show me the code where it happens? >> >> When the guest writes to HOST/GUEST_IA32_EFER, we will store this in t= he >> vmcs that will then become the active one on next L1/L2 entry, no? >> > Guest writes are stored in vmcs12 which is not HW vmcs, just a format > kvm uses internally (see vmcs12_write_any). During guest entry vmcs02=20 > is constructed from vmcs12 (see prepare_vmcs02) and this function does > not access HOST/GUEST_IA32_EFER directly, it uses vmx_set_efer instead > which takes care of things. Same function access GUEST_IA32_PAT directl= y > though. OK, right. Is it also safe to write to any field of a shadow VMCS? That's currently hypothetical, but what if the host supports shadowing but not EFER loading? I don't see a technical reason but also no clear statement in the SDM regarding this scenario. Jan --cqU7Pv0Gx6fEDb6rBgObgNuGopd0DrNmR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIAsUoACgkQitSsb3rl5xS+zQCg1tOJvceH2r0ii/+2btBeREJq 0wAAoLcq9JdyDkGivfaKvNPQi1TtR5zg =ld7m -----END PGP SIGNATURE----- --cqU7Pv0Gx6fEDb6rBgObgNuGopd0DrNmR--