From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [RFC PATCH 5/5] KVM: PPC: Take the SRCU lock around memslot use Date: Wed, 15 Aug 2012 18:16:22 +1000 Message-ID: <1345018582.2564.20.camel@pasglop> References: <20120806100207.GA8980@bloggs.ozlabs.ibm.com> <20120806100816.GF8980@bloggs.ozlabs.ibm.com> <20120809182717.GC12285@amt.cnet> <20120810003715.GC26420@bloggs.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Paul Mackerras , Marcelo Tosatti , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Alexander Graf Return-path: In-Reply-To: Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Fri, 2012-08-10 at 11:27 +0200, Alexander Graf wrote: > > 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. > > My general approach to these things is "keep it as close to x86 as we > can", because that'll make it easier for generic code to work. I don't > know if the above scheme would work for you though, since you probably > want the lock held in real mode, right? Well it wouldn't in the sense that we would still have to keep it held while running the guest on "HV" KVM. I've had a look at whether it would be feasible to hack a variant of the srcu_read_lock that's usable in real mode but it looks like it uses dynamically allocated per-cpu vars and these are in some funky vmalloc space.... We could -still- try to get to them by doing some funky page table walking but it becomes fairly hairy. And that code would be fragile and prone to breakage if the SRCU code changes. So it is an option but not one I'm happy to contemplate at this point. Cheers, Ben.