On Wed, Jun 22, 2011 at 11:03 PM, Andrea Arcangeli <aarcange@xxxxxxxxxx> wrote: > On Tue, Jun 21, 2011 at 09:32:39PM +0800, Nai Xia wrote: >> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >> index d48ec60..b407a69 100644 >> --- a/arch/x86/kvm/vmx.c >> +++ b/arch/x86/kvm/vmx.c >> @@ -4674,6 +4674,7 @@ static int __init vmx_init(void) >> kvm_mmu_set_mask_ptes(0ull, 0ull, 0ull, 0ull, >> VMX_EPT_EXECUTABLE_MASK); >> kvm_enable_tdp(); >> + kvm_dirty_update = 0; >> } else >> kvm_disable_tdp(); >> > > Why not return !shadow_dirty_mask instead of adding a new var? > >> struct mmu_notifier_ops { >> + int (*dirty_update)(struct mmu_notifier *mn, >> + struct mm_struct *mm); >> + > > Needs some docu. OK. I'll add it. > > I think dirty_update isn't self explanatory name. I think > "has_test_and_clear_dirty" would be better. Agreed. So it will be the name in the next version. :) Thanks, Nai > > If we don't flush the smp tlb don't we risk that we'll insert pages in > the unstable tree that are volatile just because the dirty bit didn't > get set again on the spte? > > The first patch I guess it's a sign of hugetlbfs going a little over > the edge in trying to mix with the core VM... Passing that parameter > &need_pte_unmap all over the place not so nice, maybe it'd be possible > to fix within hugetlbfs to use a different method to walk the hugetlb > vmas. I'd prefer that if possible. > > Thanks, > Andrea > -- 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