Re: [PATCH v2 3/5] KVM: Flush TLB in mmu notifier without holding mmu_lock

[Avi Kivity <avi@redhat.com>]

On 07/02/2012 03:05 PM, Avi Kivity wrote:
> We need something for lockbreaking too:
> 
>    def mmu_lockbreak():
>        if not (contended or need_resched):
>            return False
>        remember flush counter
>        cond_resched_lock
>        return flush counter changed
> 
> The caller would check the return value to see if it needs to redo
> anything.  But this has the danger of long operations (like write
> protecting a slot) never completing.

In fact I don't think we need the return value.  All long running
operations can tolerate a lock break.

kvm_mmu_change_mmu_pages: so long as the counter is maintained
correctly, it will function.  May livelock though, so we should abort if
we don't manage to keep the counter down.

get_dirty_log: so long as a write fault updates the next bitmap, we're fine

kvm_mmu_slot_remove_write_access: same.  It's hard to continue the loop
after a lockbreak though.  We can switch it to be rmap based instead.

flush_shadow (zap_all): just restart from the beginning after dropping
the lock.  May livelock, can be fixed by using a generation counter for
kvm_mmu_page.

kvm_mmu_sync_roots: already does lockbreaking

kvm_mmu_unprotect_page: not long-running in normal operation, but a
guest can make it long running.  However, we're allowed not to be
accurate about it and just return to the guest.

kvm_mmu_pte_write: can be a long operation with crazy guests. Normal
guests will work fine.

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