On 11/01/2018 03:25 AM, Wanpeng Li wrote: > On Thu, 1 Nov 2018 at 05:55, Junaid Shahid <junaids@xxxxxxxxxx> wrote: >> >> When a guest page table is updated via an emulated write, >> kvm_mmu_pte_write() is called to update the shadow PTE using the just >> written guest PTE value. But if two emulated guest PTE writes happened >> concurrently, it is possible that the guest PTE and the shadow PTE end >> up being out of sync. Emulated writes do not mark the shadow page as >> unsync-ed, so this inconsistency will not be resolved even by a guest TLB >> flush (unless the page was marked as unsync-ed at some other point). >> >> This is fixed by re-reading the current value of the guest PTE after the >> MMU lock has been acquired instead of just using the value that was >> written prior to calling kvm_mmu_pte_write(). >> >> Signed-off-by: Junaid Shahid <junaids@xxxxxxxxxx> > > Reviewed-by: Wanpeng Li <wanpengli@xxxxxxxxxxx> > > PTE lock is expected to be held in the guest to avoid concurrently > updating as what commercialized OS like linux pte_lockptr() does. > Yes, but we need to have correct behavior regardless of what the guest does. Besides, even Linux does have some places where PTE modification is done without locks. KVM's fast page fault path is one obvious example.
