On 10.08.2012, at 02:37, Paul Mackerras wrote: > 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. 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? Alex -- 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
