On Thu, May 02, 2013 at 11:22:52AM -0700, David Daney wrote: > Hi, > > I am working on the MIPS KVM port, and am trying to figure out under > which circumstances do I need to srcu_read_lock()/srcu_read_unlock() > the kvm->srcu. For x86: kvm->srcu protects memory slot information (kvm->memslots) and in-kernel MMIO/PIO address->device structure mapping (kvm->buses). Search for synchronize_srcu_expedited() in virt/kvm/ to locate the updaters. > I am looking at implementing something similar to arch/x86/kvm/x86.c > at __msr_io(), where we see: > > . > . > . > idx = srcu_read_lock(&vcpu->kvm->srcu); > for (i = 0; i < msrs->nmsrs; ++i) > if (do_msr(vcpu, entries[i].index, &entries[i].data)) > break; > srcu_read_unlock(&vcpu->kvm->srcu, idx); > . > . > . > > Why is the srcu_read_lock() taken here? I see no srcu_dereference() > in the code path that would indicate the need for obtaining the > lock. case KVM_GET_MSRS: r = msr_io(vcpu, argp, kvm_get_msr, 1); break; case KVM_SET_MSRS: r = msr_io(vcpu, argp, do_set_msr, 0); break; to int kvm_get_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata) { return kvm_x86_ops->get_msr(vcpu, msr_index, pdata); } Somewhere down that path memslot information must be accessed. > I have a feeling that I am missing some essential concept about the > design of this code, but I don't know what it is. > > Can someone explain what is happening here? For x86 the usage is: VCPU CODE PATH -------------- IOCTL(KVM_FD, KVM_VCPU_RUN) ENTER-KERNEL SRCU_READ_LOCK() ... large parte of vcpu context code performed with srcu lock held, so that memory slot information can be used to access guest memory (gfn_to_memslot for example). SRCU_READ_UNLOCK() VMENTER while in guest mode srcu is not held so that updaters can make progress VMEXIT SRCU_READ_LOCK() back to vcpu context code SRCU_READ_UNLOCK before return to userspace. Also, when emulating HALT (kvm_vcpu_block) srcu is dropped. UPDATERS -------- See synchronize_srcu_expedited in virt/kvm/ -- 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