On 2013-03-14 11:15, Jan Kiszka wrote: >>> >>> - if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED)) { >>> - pr_debug("vcpu %d received sipi with vector # %x\n", >>> - vcpu->vcpu_id, vcpu->arch.sipi_vector); >>> - kvm_lapic_reset(vcpu); >>> - kvm_vcpu_reset(vcpu); >>> - vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE; >>> - } >>> - >>> vcpu->srcu_idx = srcu_read_lock(&kvm->srcu); >>> r = vapic_enter(vcpu); >> >> vmx_vcpu_reset overwrites vcpu->srcu_idx if ->vcpu_reset is called from >> within srcu section. > > Indeed. > > Do you know what the look over vmx_set_cr0 actually protects? Found it: It's not actually protecting anything. enter_rmode is called, and that assumes that lock to be held. If enter_rmode faces an uninitialized tss, it drops the lock before calling vmx_set_tss_addr. Well, I wonder if that is a good place to fix the TSS issue. Why not make that special case (lacking KVM_SET_TSS_ADDR before first KVM_RUN) a static jump key and check for it on KVM_RUN? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- 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