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