From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] KVM: x86: conditionally acquire/release slots_lock on entry/exit Date: Mon, 14 Sep 2009 08:03:49 +0300 Message-ID: <4AADCEB5.7040800@redhat.com> References: <20090827012000.762063112@localhost.localdomain> <20090827155450.GA6312@amt.cnet> <4A96B404.5010500@redhat.com> <20090827225940.GA13571@amt.cnet> <4A977E3C.7050604@redhat.com> <20090910223003.GA658@amt.cnet> <4AAD12F9.5020601@redhat.com> <20090913162652.GF6867@linux.vnet.ibm.com> <20090913224956.GA5142@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. McKenney" , kvm@vger.kernel.org, Gleb Natapov To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56199 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbZINFDx (ORCPT ); Mon, 14 Sep 2009 01:03:53 -0400 In-Reply-To: <20090913224956.GA5142@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 09/14/2009 01:49 AM, Marcelo Tosatti wrote: > >>> I think synchronize_srcu() will be deferred until the fault path is >>> complete (and srcu_read_unlock() runs). Copying someone who knows for >>> sure. >>> >> Yes, synchronize_srcu() will block until srcu_read_unlock() in this >> scenario, assuming that the same srcu_struct is used by both. >> > Right it will. But this does not stop the fault path from creating > shadow pages with stale sp->gfn (the only way to do that would be mutual > exclusion AFAICS). > So we put the kvm_mmu_zap_pages() call as part of the synchronize_srcu() callback to take advantage of the srcu guarantees. We know that when when the callback is called all new reads see the new slots and all old readers have completed. > The RCU read-protected side does not stop a new memslots pointer from > being assigned (with rcu_assign_pointer), does it? > > It doesn't. It only gives you a point in time where you know no one is using the old pointer, but before it has been deleted. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.