[PATCH 0/9] KVM: MTRR fixes and some cleanups

From: guangrong . xiao
Date: Thu Apr 30 2015 - 10:50:41 EST

From: Xiao Guangrong <guangrong.xiao@xxxxxxxxxxxxxxx>

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 2 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 1 of mtrr_state->enabled (bit

3: if MTRR is disabled, UC is applied to all of physical memory rather than

- 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 (9):
KVM: MMU: fix decoding cache type from MTRR
KVM: MMU: introduce slot_handle_level() and its helper
KVM: MMU: use slot_handle_level and its helper to clean up the code
KVM: MMU: introduce for_each_rmap_spte()
KVM: MMU: KVM: introduce for_each_slot_rmap
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/include/asm/kvm_host.h | 2 +
arch/x86/kvm/mmu.c | 407 ++++++++++++++++++++++------------------
arch/x86/kvm/mmu.h | 1 +
arch/x86/kvm/mmu_audit.c | 4 +-
arch/x86/kvm/svm.c | 5 +
arch/x86/kvm/vmx.c | 58 ++++++
arch/x86/kvm/x86.c | 5 +-
7 files changed, 294 insertions(+), 188 deletions(-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/