From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bandan Das Subject: Re: [RFC PATCH 3/4] mmu: don't set the present bit unconditionally Date: Wed, 22 Jun 2016 12:23:31 -0400 Message-ID: References: <1466478746-14153-1-git-send-email-bsd@redhat.com> <1466478746-14153-4-git-send-email-bsd@redhat.com> <85afcdbf-f2aa-cc90-10ac-f8e25342c266@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: kvm@vger.kernel.org, guangrong.xiao@linux.intel.com To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44610 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752147AbcFVQXn (ORCPT ); Wed, 22 Jun 2016 12:23:43 -0400 In-Reply-To: (Paolo Bonzini's message of "Wed, 22 Jun 2016 18:12:01 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Paolo Bonzini writes: > On 22/06/2016 18:10, Bandan Das wrote: >>>> >> + if (!shadow_xonly_valid) >>>> >> + spte = PT_PRESENT_MASK; >>>> >> if (!speculative) >>>> >> spte |= shadow_accessed_mask; >>>> >> >>>> >> @@ -2537,8 +2538,12 @@ static int set_spte(struct kvm_vcpu *vcpu, u64 *sptep, >>>> >> else >>>> >> spte |= shadow_nx_mask; >>>> >> >>>> >> - if (pte_access & ACC_USER_MASK) >>>> >> - spte |= shadow_user_mask; >>>> >> + if (pte_access & ACC_USER_MASK) { >>>> >> + if (shadow_xonly_valid) >>>> >> + spte |= PT_PRESENT_MASK; >>>> >> + else >>>> >> + spte |= shadow_user_mask; >>>> >> + } >>> > >>> > Can you instead pass VMX_READABLE_MASK to kvm_mmu_set_mask_ptes in vmx.c? >> So, leave spte = PT_PRESENT_MASK as is and make VMX_READABLE_MASK 1ULL if >> execute only is supported ? >> And then : >> if !(pte_access & ACC_USER_MASK) { >> spte &= ~VMX_READABLE_MASK >> > > No, I meant something like > > spte = 0; > if (!shadow_xonly_valid) > spte = PT_PRESENT_MASK; > ... > if (pte_access & ACC_USER_MASK) > spte |= shadow_user_mask; Ok, Xiao mentioned this too. I will fix it in the next version. Thanks for the review. > Paolo > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html