summaryrefslogtreecommitdiffstats
path: root/include/memory
diff options
context:
space:
mode:
authorSean Christopherson <sean.j.christopherson@intel.com>2019-02-05 21:54:17 +0100
committerPaolo Bonzini <pbonzini@redhat.com>2019-02-20 22:48:32 +0100
commit152482580a1b0accb60676063a1ac57b2d12daf6 (patch)
tree4c87b94da258dd28ff3e8da0c7efb5c8b6c5da68 /include/memory
parentkvm: vmx: Add memcg accounting to KVM allocations (diff)
downloadlinux-152482580a1b0accb60676063a1ac57b2d12daf6.tar.xz
linux-152482580a1b0accb60676063a1ac57b2d12daf6.zip
KVM: Call kvm_arch_memslots_updated() before updating memslots
kvm_arch_memslots_updated() is at this point in time an x86-specific hook for handling MMIO generation wraparound. x86 stashes 19 bits of the memslots generation number in its MMIO sptes in order to avoid full page fault walks for repeat faults on emulated MMIO addresses. Because only 19 bits are used, wrapping the MMIO generation number is possible, if unlikely. kvm_arch_memslots_updated() alerts x86 that the generation has changed so that it can invalidate all MMIO sptes in case the effective MMIO generation has wrapped so as to avoid using a stale spte, e.g. a (very) old spte that was created with generation==0. Given that the purpose of kvm_arch_memslots_updated() is to prevent consuming stale entries, it needs to be called before the new generation is propagated to memslots. Invalidating the MMIO sptes after updating memslots means that there is a window where a vCPU could dereference the new memslots generation, e.g. 0, and incorrectly reuse an old MMIO spte that was created with (pre-wrap) generation==0. Fixes: e59dbe09f8e6 ("KVM: Introduce kvm_arch_memslots_updated()") Cc: <stable@vger.kernel.org> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'include/memory')
0 files changed, 0 insertions, 0 deletions