Re: [PATCH] kvm memslot read-locking with mmu_lock

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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.

>> What are the new lookup rules?  We don't hold mmu_lock everywhere we look 
>> up a gfn, do we?
>>     
>
> It's safe to loop over the memslots by just skipping the ones with
> userland_addr == 0 by only holding the mmu_lock. The memslots contents
> can't change by holding the mmu_lock. The mmu_lock also serializes the
> rmap structures inside the memslot and the spte updates. So by just
> taking the mmu_lock it's trivial to do "search memslot", "translate
> the hva to its relative rmapp", "find all sptes relative to the hva
> and overwrite them with nonpresent-fault".
>
>   

But we lookup memslots in parallel in the guest walker and similar 
places, relying on mmap_sem being taken for read.

Maybe we need a rwlock instead, and drop this overloaded usage of mmap_sem.

> If the mmu_notifiers would have been registered inside the vma things
> would look very different in this area and it might have been possible
> to embed the mmu-notifier inside the memslot itself, to avoid the
> "search memslot" op.
>   

Nothing guarantees a 1:1 mapping between memslots and vma.  You can have 
a vma backing multiple memslots, or a memslot spanning multiple vmas.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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/