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 <paulus@xxxxxxxxx> > > --- > > 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. -- 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
