On Thu, Aug 7, 2014 at 6:36 PM, Xiao Guangrong <xiaoguangr...@linux.vnet.ibm.com> wrote: > On 08/08/2014 02:32 AM, David Matlack wrote: >> The following events can lead to an incorrect KVM_EXIT_MMIO bubbling >> up to userspace: >> >> (1) Guest accesses gpa X without a memory slot. The gfn is cached in >> struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets >> the SPTE write-execute-noread so that future accesses cause >> EPT_MISCONFIGs. >> >> (2) Host userspace creates a memory slot via KVM_SET_USER_MEMORY_REGION >> covering the page just accessed. >> >> (3) Guest attempts to read or write to gpa X again. On Intel, this >> generates an EPT_MISCONFIG. The memory slot generation number that >> was incremented in (2) would normally take care of this but we fast >> path mmio faults through quickly_check_mmio_pf(), which only checks >> the per-vcpu mmio cache. Since we hit the cache, KVM passes a >> KVM_EXIT_MMIO up to userspace. >> >> This patch fixes the issue by using the memslot generation number >> to validate the mmio cache. >> >> Signed-off-by: David Matlack <dmatl...@google.com> >> --- >> The patch diff is rather large because I had to pull some code out >> of x86.h and mmu.c and into mmu.h. The main change is adding the >> memslot generation in vcpu_cach_mmio_info() and then validating >> that slot in vcpu_match_mmio_*(). > > Why not just move vcpu_cach_mmio_info() into mmu.c where is > the only place vcpu_cach_mmio_info is called. :)
If only it was so simple :). vcpu_match_mmio_*() now needs kvm_current_mmio_generation() which *was* in mmu.c. vcpu_match_mmio_*() is called from x86.c and mmu.c so all that has to go in a header. I decided to keep vcpu_cache_mmio_info() with the rest for organization's sake. > BTW, i will post a patch to fix the generation-number issue > soon. > > Great! Thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
