On Fri, Apr 03, 2009 at 06:45:48PM -0300, Marcelo Tosatti wrote: > On Tue, Mar 24, 2009 at 11:47:33AM +0200, Avi Kivity wrote: > >> index 2ea8262..48169d7 100644 > >> --- a/arch/x86/kvm/x86.c > >> +++ b/arch/x86/kvm/x86.c > >> @@ -3109,6 +3109,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) > >> kvm_write_guest_time(vcpu); > >> if (test_and_clear_bit(KVM_REQ_MMU_SYNC, &vcpu->requests)) > >> kvm_mmu_sync_roots(vcpu); > >> + if (test_and_clear_bit(KVM_REQ_MMU_GLOBAL_SYNC, &vcpu->requests)) > >> + kvm_mmu_sync_global(vcpu); > >> if (test_and_clear_bit(KVM_REQ_TLB_FLUSH, &vcpu->requests)) > >> kvm_x86_ops->tlb_flush(vcpu); > >> if (test_and_clear_bit(KVM_REQ_REPORT_TPR_ACCESS > > > > Windows will (I think) write a PDE on every context switch, so this > > effectively disables global unsync for that guest. > > > > What about recursively syncing the newly linked page in FNAME(fetch)()? > > If the page isn't global, this becomes a no-op, so no new overhead. The > > only question is the expense when linking a populated top-level page, > > especially in long mode. > > How about this? > > KVM: MMU: sync global pages on fetch() > > If an unsync global page becomes unreachable via the shadow tree, which > can happen if one its parent pages is zapped, invlpg will fail to > invalidate translations for gvas contained in such unreachable pages. > > So sync global pages in fetch(). > > Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx> I have tried this patch, and unfortunately it does not solve the original problem, while the previous one did. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@xxxxxxxxxxx http://www.aurel32.net -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
