On Mon, Mar 31, 2008 at 09:35:00AM +0300, Avi Kivity wrote: > This can be done by taking mmu_lock in _begin and releasing it in _end, > unless there's a lock dependency issue.
The main problem is if want to be able to co-exit with XPMEM methods registered in the same notifier chain for the same MM with the KVM methods. The ideal would be to solve the race with a non-blocking lock like seqlock. > I don't understand your conclusion: you prove that mlock() is not good > enough, then post a patch to do it? mlock isn't good enough to allow munmap/madvise(don't need). So mlock fixes the race in the current kvm code, but only unless you use ballooning. This is because VM_LOCKED should be ignored by madvise(don't need). But at least this is only a trouble for smp guest. It'd require rmap_remove to run on a different physical cpu while another qemu thread runs madvise. So supposedly with an up guest, the guest won't run rmap_remove while madvise runs. To better explain the race, if we could take the mmu_lock around madvise that would fix it for smp guest too (however currently it's userland calling into madvise so that's not feasible with the current model). > I'll take another shot at fixing rmap_remove(), I don't like to cripple > swapping for 2.6.25 (though it will only be really dependable in .26). Ok! Clearly it would look more robust if rmap_remove is capable of doing the last free on the page and it won't relay on the page not to be freed until mmu_lock is released. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
