Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932110AbbEMGqH (ORCPT ); Wed, 13 May 2015 02:46:07 -0400 Received: from mga03.intel.com ([134.134.136.65]:13162 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753583AbbEMGqB (ORCPT ); Wed, 13 May 2015 02:46:01 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,419,1427785200"; d="scan'208";a="492939036" From: Xiao Guangrong To: pbonzini@redhat.com Cc: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Xiao Guangrong Subject: [PATCH v3 00/10] KVM: MTRR fixes and some cleanups Date: Wed, 13 May 2015 14:42:18 +0800 Message-Id: <1431499348-25188-1-git-send-email-guangrong.xiao@linux.intel.com> X-Mailer: git-send-email 2.1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2875 Lines: 73 Changelog in v3: thanks for Paolo's comment: - do not apply for_each_rmap_spte to kvm_zap_rmapp and kvm_mmu_unlink_parents - fix a cosmetic issue in slot_handle_level_range - introduce PT_MAX_HUGEPAGE_LEVEL to clean up the code - improve code Indentation Changelog in v2: - fix the bit description in changelog of the first patch, thanks David Matlack for pointing it out all follow changes are from Paolo's comment and really appreciate it: - reorder the whole patchset to make it is more readable - redesign the iterator APIs - make TLB clean if @lock_flush_tlb is true in slot_handle_level() - make MTRR update be generic This are some MTRR bugs if legacy IOMMU device is used on Intel's CPU: - In current code, whenever guest MTRR registers are changed kvm_mmu_reset_context is called to switch to the new root shadow page table, however, it's useless since: 1) the cache type is not cached into shadow page's attribute so that the original root shadow page will be reused 2) the cache type is set on the last spte, that means we should sync the last sptes when MTRR is changed We can fix it by dropping all the spte in the gfn range which is being updated by MTRR - some bugs are in get_mtrr_type(); 1: bit 1 of mtrr_state->enabled is corresponding bit 11 of IA32_MTRR_DEF_TYPE MSR which completely control MTRR's enablement that means other bits are ignored if it is cleared 2: the fixed MTRR ranges are controlled by bit 0 of mtrr_state->enabled (bit 10 of IA32_MTRR_DEF_TYPE) 3: if MTRR is disabled, UC is applied to all of physical memory rather than mtrr_state->def_type - we need not to reset mmu once cache policy is changed since shadow page table does not virtualize any cache policy Also, these are some cleanups to make current MMU code more cleaner and help us fixing the bug more easier. Xiao Guangrong (10): KVM: MMU: fix decoding cache type from MTRR KVM: MMU: introduce for_each_rmap_spte() KVM: MMU: introduce PT_MAX_HUGEPAGE_LEVEL KVM: MMU: introduce for_each_slot_rmap_range KVM: MMU: introduce slot_handle_level_range() and its helpers KVM: MMU: use slot_handle_level and its helper to clean up the code KVM: MMU: introduce kvm_zap_rmapp KVM: MMU: introduce kvm_zap_gfn_range KVM: MMU: fix MTRR update KVM: x86: do not reset mmu if CR0.CD and CR0.NW are changed arch/x86/kvm/mmu.c | 409 +++++++++++++++++++++++++---------------------- arch/x86/kvm/mmu.h | 2 + arch/x86/kvm/mmu_audit.c | 4 +- arch/x86/kvm/x86.c | 62 ++++++- 4 files changed, 281 insertions(+), 196 deletions(-) -- 2.1.0 -- 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/