Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758172AbbGHGEn (ORCPT ); Wed, 8 Jul 2015 02:04:43 -0400 Received: from mga01.intel.com ([192.55.52.88]:28732 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752202AbbGHGEd (ORCPT ); Wed, 8 Jul 2015 02:04:33 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,429,1432623600"; d="scan'208";a="602108235" Message-ID: <559CBC4E.2090004@linux.intel.com> Date: Wed, 08 Jul 2015 13:59:42 +0800 From: Xiao Guangrong User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org CC: jroedel@suse.de, alex.williamson@redhat.com, ogerlitz@mellanox.com, amirv@mellanox.com Subject: Re: [PATCH 2/4] KVM: SVM: use NPT page attributes References: <1436276739-50326-1-git-send-email-pbonzini@redhat.com> <1436276739-50326-3-git-send-email-pbonzini@redhat.com> In-Reply-To: <1436276739-50326-3-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2959 Lines: 84 On 07/07/2015 09:45 PM, Paolo Bonzini wrote: > Right now, NPT page attributes are not used, and the final page > attribute depends solely on gPAT (which however is not synced > correctly), the guest MTRRs and the guest page attributes. > > However, we can do better by mimicking what is done for VMX. > In the absence of PCI passthrough, the guest PAT can be ignored > and the page attributes can be just WB. If passthrough is being > used, instead, keep respecting the guest PAT, and emulate the guest > MTRRs through the PAT field of the nested page tables. > > The only snag is that WP memory cannot be emulated correctly, > because Linux's default PAT setting only includes the other types. > > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/svm.c | 47 ++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 42 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > index 602b974a60a6..0f125c1860ec 100644 > --- a/arch/x86/kvm/svm.c > +++ b/arch/x86/kvm/svm.c > @@ -1085,6 +1085,47 @@ static u64 svm_compute_tsc_offset(struct kvm_vcpu *vcpu, u64 target_tsc) > return target_tsc - tsc; > } > > +static void svm_set_guest_pat(struct vcpu_svm *svm, u64 *g_pat) > +{ > + struct kvm_vcpu *vcpu = &svm->vcpu; > + > + /* Unlike Intel, AMD takes the guest's CR0.CD into account. I noticed this code in svm_set_cr0(): if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_CD_NW_CLEARED)) cr0 &= ~(X86_CR0_CD | X86_CR0_NW); gCR0.CD is hidden to CPU if KVM_QUIRK_CD_NW_CLEARED is not set and looks like it is the normal case after grepping Qemu code. > + * > + * AMD does not have IPAT. To emulate it for the case of guests > + * with no assigned devices, just set everything to WB. If guests > + * have assigned devices, however, we cannot force WB for RAM > + * pages only, so use the guest IPAT as passed. > + */ > + if (!kvm_arch_has_assigned_device(vcpu->kvm)) > + *g_pat = 0x0606060606060606; > + else > + *g_pat = vcpu->arch.pat; > +} > + > +static u64 svm_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio) > +{ > + u8 cache; > + > + /* > + * 1. MMIO: always map as UC > + * 2. No passthrough: always map as WB, and force guest PAT to WB as well > + * 3. Passthrough: can't guarantee the result, try to trust guest. > + */ > + if (is_mmio) > + return _PAGE_NOCACHE; > + > + if (!kvm_arch_has_assigned_device(vcpu->kvm)) > + return 0; > + > + cache = kvm_mtrr_get_guest_memory_type(vcpu, gfn); > + @cache return from kvm_mtrr_get_guest_memory_type is MTRR_TYPE_* which is different with _PAGE_CACHE_MODE_*. The latter is pure SW usage, e.g: _PAGE_CACHE_MODE_WB = 0 and #define MTRR_TYPE_WRBACK 6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/