From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v3 5/6] KVM: nVMX: Update mmu.base_role.nxe after EFER loading on VM-entry/exit Date: Tue, 03 Sep 2013 11:32:10 +0200 Message-ID: <5225AC9A.1030600@siemens.com> References: <08db7d166ab05ce133300ba069c0728f5c97120b.1375971992.git.jan.kiszka@siemens.com> <20130903083939.GV22899@redhat.com> <5225A313.1070700@siemens.com> <20130903090411.GX22899@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , kvm , Xiao Guangrong , Jun Nakajima , Yang Zhang , Arthur Chunqi Li To: Gleb Natapov Return-path: Received: from thoth.sbs.de ([192.35.17.2]:27180 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932539Ab3ICJcX (ORCPT ); Tue, 3 Sep 2013 05:32:23 -0400 In-Reply-To: <20130903090411.GX22899@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2013-09-03 11:04, Gleb Natapov wrote: > On Tue, Sep 03, 2013 at 10:51:31AM +0200, Jan Kiszka wrote: >> On 2013-09-03 10:39, Gleb Natapov wrote: >>> On Thu, Aug 08, 2013 at 04:26:32PM +0200, Jan Kiszka wrote: >>>> This job is normally performed by the architectural EFER set service >>>> which we cannot use as it prevents transitions that are valid when >>>> switching between L1 and L2. So open-code the update of base_role.nxe >>>> after changing EFER on VM-entry and exit. >>>> >>>> Signed-off-by: Jan Kiszka >>>> --- >>>> arch/x86/kvm/vmx.c | 4 ++++ >>>> 1 files changed, 4 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >>>> index 9b0510b..7cc208a 100644 >>>> --- a/arch/x86/kvm/vmx.c >>>> +++ b/arch/x86/kvm/vmx.c >>>> @@ -7735,6 +7735,8 @@ static void prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12) >>>> vcpu->arch.efer &= ~(EFER_LMA | EFER_LME); >>>> /* Note: modifies VM_ENTRY/EXIT_CONTROLS and GUEST/HOST_IA32_EFER */ >>>> vmx_set_efer(vcpu, vcpu->arch.efer); >>>> + vcpu->arch.mmu.base_role.nxe = >>>> + (vcpu->arch.efer & EFER_NX) && !enable_ept; >>>> >>> kvm_mmu_reset_context() called later in this function does that. >> >> For all relevant scenarios? The code is pretty convoluted, so this is >> non-obvious for me: kvm_mmu_reset_context calls init_kvm_mmu which may >> call init_kvm_softmmu that does kvm_init_shadow_mmu with nxe >> initialization. But is that path always taken? >> > What scenarios are relevant here? kvm_mmu_reset_context() is what > kvm_set_efer() would have called anyway. Since you use !enable_ept > here I assume that relevant scenario is shadow on shadow and in this > case it is easy to see that kvm_mmu_reset_context() will call > kvm_init_shadow_mmu() eventually. For all other scenarios guest nx > setting is irrelevant. Indeed... Ah! I missed that 2c9afa52 changed the picture. OK, another obsolete one. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux