From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2 3/5] KVM: Flush TLB in mmu notifier without holding mmu_lock Date: Mon, 02 Jul 2012 15:41:30 +0300 Message-ID: <4FF196FA.9020309@redhat.com> References: <1337250284-18607-1-git-send-email-avi@redhat.com> <1337250284-18607-3-git-send-email-avi@redhat.com> <20120521205850.GA27076@amt.cnet> <4FF18E7D.7020102@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Xiao Guangrong , Takuya Yoshikawa , kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:12481 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752606Ab2GBMli (ORCPT ); Mon, 2 Jul 2012 08:41:38 -0400 In-Reply-To: <4FF18E7D.7020102@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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