On Tue, Jan 22, 2008 at 04:38:49PM +0200, Avi Kivity wrote: > Andrea Arcangeli wrote: >> >>> This is arch independent code, I'm surprised mmu_lock is visible here? >>> >> >> The mmu_lock is arch independent as far as I can tell. Pretty much >> like the mm->page_table_lock is also independent. All archs will have >> some form of shadow pagetables in software or hardware, and mmu_lock >> is the lock to take to serialize the pagetable updates and it also >> allows to walk the memslots in readonly mode. >> >> > > Well, s390 has everything in hardware, but I suppose they can just ignore > the lock.
If they don't take it in their lowlevel it's enough I think. It'll still be useful to lookup memslots like in every other arch. > But we lookup memslots in parallel in the guest walker and similar places, > relying on mmap_sem being taken for read. That's ok. The vmas could also be looked up either with mmap_sam in read mode or with only the page_table_lock taken (these days it doesn't work anymore with ptlocks). The mmu_lock is only taken in the modifications of the memslots, the lookups don't require it. The modifications have to take both mmap_sem in write mode and the mmu_lock. Lookups requires either mmap_sem in read mode or the mmu_lock. The lookups with mmap_sem in read mode won't ever see a userspace_addr =0, the mmu_lock have to skip over the userspace_addr=0 instead. > Maybe we need a rwlock instead, and drop this overloaded usage of mmap_sem. Adding another lock just for the memslots should be feasible. However it can't be a semaphore or it won't work for the mmu-notifiers. A rwlock would be ok, but then all memslots lookups will have to be updated to check for userspace_addr != 0 like the kvm_hva_to_rmapp does. > Nothing guarantees a 1:1 mapping between memslots and vma. You can have a > vma backing multiple memslots, or a memslot spanning multiple vmas. Yes, that's why it would add complications to have it in the vma, one would need to add a vma split to guarantee the 1:1 mapping, and then it'd be a bit faster too (though the memslots can easily be rbtree-indexed). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
