On Thu, Aug 09, 2012 at 03:22:38PM -0300, Marcelo Tosatti wrote: > 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? I take and release the SRCU lock inside the guest entry loop, so in fact we will release the SRCU lock every time we pop out of the guest. As for holding the SRCU read lock while we're in the guest - that is what enables us to do H_ENTER etc. (the hypercalls that the guest uses to update the hardware page table) in real mode, i.e. without switching the MMU over to the kernel context. In real mode we can access the linear mapping but not vmalloc, ioremap or user space, so I am nervous about doing srcu_read_lock/unlock in real mode. I really don't want to switch to kernel mode for those hypercalls because that switch is relatively slow and requires pulling all of the SMT threads in the core out of the guest (because of hardware restrictions). So, holding the SRCU read lock while in the guest is the least ugly approach AFAICS. Yes it makes memslot addition/removal a bit slower, but only for this VM, and it doesn't delay grace periods for other forms of RCU, so its impact is pretty limited. 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
