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. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
