Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751497AbbEGQx3 (ORCPT ); Thu, 7 May 2015 12:53:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45105 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751236AbbEGQx0 (ORCPT ); Thu, 7 May 2015 12:53:26 -0400 Message-ID: <554B987E.2060603@redhat.com> Date: Thu, 07 May 2015 18:53:18 +0200 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: guangrong.xiao@linux.intel.com CC: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 8/9] KVM: MMU: fix MTRR update References: <1430389490-24602-1-git-send-email-guangrong.xiao@linux.intel.com> <1430389490-24602-9-git-send-email-guangrong.xiao@linux.intel.com> In-Reply-To: <1430389490-24602-9-git-send-email-guangrong.xiao@linux.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2162 Lines: 72 On 30/04/2015 12:24, guangrong.xiao@linux.intel.com wrote: > +static void vmx_set_msr_mtrr(struct kvm_vcpu *vcpu, u32 msr) > +{ > + struct mtrr_state_type *mtrr_state = &vcpu->arch.mtrr_state; > + unsigned char mtrr_enabled = mtrr_state->enabled; > + gfn_t start, end, mask; > + int index; > + bool is_fixed = true; > + > + if (msr == MSR_IA32_CR_PAT || !enable_ept || > + !kvm_arch_has_noncoherent_dma(vcpu->kvm)) > + return; > + > + if (!(mtrr_enabled & 0x2) && msr != MSR_MTRRdefType) > + return; > + > + switch (msr) { > + case MSR_MTRRfix64K_00000: > + start = 0x0; > + end = 0x80000; > + break; > + case MSR_MTRRfix16K_80000: > + start = 0x80000; > + end = 0xa0000; > + break; > + case MSR_MTRRfix16K_A0000: > + start = 0xa0000; > + end = 0xc0000; > + break; > + case MSR_MTRRfix4K_C0000 ... MSR_MTRRfix4K_F8000: > + index = msr - MSR_MTRRfix4K_C0000; > + start = 0xc0000 + index * (32 << 10); > + end = start + (32 << 10); > + break; > + case MSR_MTRRdefType: > + is_fixed = false; > + start = 0x0; > + end = ~0ULL; > + break; > + default: > + /* variable range MTRRs. */ > + is_fixed = false; > + index = (msr - 0x200) / 2; > + start = (((u64)mtrr_state->var_ranges[index].base_hi) << 32) + > + (mtrr_state->var_ranges[index].base_lo & PAGE_MASK); > + mask = (((u64)mtrr_state->var_ranges[index].mask_hi) << 32) + > + (mtrr_state->var_ranges[index].mask_lo & PAGE_MASK); > + mask |= ~0ULL << cpuid_maxphyaddr(vcpu); > + > + end = ((start & mask) | ~mask) + 1; > + } > + > + if (is_fixed && !(mtrr_enabled & 0x1)) > + return; > + > + kvm_zap_gfn_range(vcpu->kvm, gpa_to_gfn(start), gpa_to_gfn(end)); > +} I think this should all be generic logic, even if it causes some extra zaps on AMD. (It's AMD's bug that it doesn't honor MTRRs). Even !enable_ept can be handled in a vendor-independent manner, as "vcpu->arch.mmu.page_fault == tdp_page_fault". Paolo -- 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/