From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Subject: Re: [RFC PATCH 5/5] KVM: PPC: Take the SRCU lock around memslot use Date: Fri, 10 Aug 2012 10:37:15 +1000 Message-ID: <20120810003715.GC26420@bloggs.ozlabs.ibm.com> References: <20120806100207.GA8980@bloggs.ozlabs.ibm.com> <20120806100816.GF8980@bloggs.ozlabs.ibm.com> <20120809182717.GC12285@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Graf , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from ozlabs.org ([203.10.76.45]:46292 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751800Ab2HJApI (ORCPT ); Thu, 9 Aug 2012 20:45:08 -0400 Content-Disposition: inline In-Reply-To: <20120809182717.GC12285@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Aug 09, 2012 at 03:27:17PM -0300, Marcelo Tosatti wrote: > On Mon, Aug 06, 2012 at 08:08:16PM +1000, Paul Mackerras wrote: > > The generic KVM code uses SRCU (sleeping RCU) to protect accesses > > to the memslots data structures against updates due to userspace > > adding, modifying or removing memory slots. We need to do that too, > > both to avoid accessing stale copies of the memslots and to avoid > > lockdep warnings. This therefore adds srcu_read_lock/unlock pairs > > around code that accesses and uses memslots in the Book 3S PR code > > and the Book E (44x and e500) code. > > > > Signed-off-by: Paul Mackerras > > --- > > Compile-tested only. > > > > arch/powerpc/kvm/44x_tlb.c | 6 ++++++ > > arch/powerpc/kvm/book3s_pr.c | 6 ++++++ > > arch/powerpc/kvm/e500_tlb.c | 6 ++++++ > > 3 files changed, 18 insertions(+) > > On top of the previous comment: > > x86 calls srcu_read_lock at the beginning of the KVM_RUN ioctl handler > (__vcpu_run in arch/x86/kvm/x86.c), unlocks srcu on guest entry, locks > on guest exit before any potential use of memslots, and unlocks on > exit to userspace. > > This has the advantage of not sprinkling srcu lock/unlock calls all over > (except from other ioctls, of course). Its low maintenance. > > Perhaps doing the same on PPC is not a bad idea. Perhaps... these changes are to areas of the PPC KVM code that I don't use or maintain, so they're really more a suggestion of one way to fix the problem than anything else. That's why I put RFC in the subject line. It would be up to Alex whether he wants to fix it like this or by taking the SRCU lock at a higher level. Paul.