On Mon, Aug 06, 2012 at 08:06:55PM +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. > > Since the real-mode handlers for H_ENTER, H_REMOVE and H_BULK_REMOVE > need to access the memslots, and we don't want to call the SRCU code > in real mode (since we have no assurance that it would only access > the linear mapping), we hold the SRCU read lock for the VM while > in the guest. This does mean that adding or removing memory slots > while some vcpus are executing in the guest will block for up to > two jiffies. This tradeoff is acceptable since adding/removing > memory slots only happens rarely, while H_ENTER/H_REMOVE/H_BULK_REMOVE > are performance-critical hot paths. I would avoid doing this. What prevents the guest entry loop in the kernel to simply reenter without ever unlocking SRCU? -- 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
