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 <jan.kiszka@xxxxxxxxxxx> >>>> --- >>>> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
