On Wed, Mar 06, 2013 at 01:12:52AM -0500, Paolo Bonzini wrote: > > > On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote: > > > On Mon, Mar 04, 2013 at 10:41:43PM +0100, Jan Kiszka wrote: > > > > From: Jan Kiszka <jan.kis...@siemens.com> > > > > > > > > A VCPU sending INIT or SIPI to some other VCPU races for setting > > > > the > > > > remote VCPU's mp_state. When we were unlucky, > > > > KVM_MP_STATE_INIT_RECEIVED > > > > was overwritten by kvm_emulate_halt and, thus, got lost. > > > > > > > > Fix this by raising requests on the sender side that will then be > > > > handled synchronously over the target VCPU context. > > > > > > > > Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> > > > > > > Why is kvm_emulate_halt being executed from > > > KVM_MP_STATE_INIT_RECEIVED/KVM_MP_STATE_SIPI_RECEIVED again? > > > > > > Why is it not true that the only valid transition from > > > KVM_MP_STATE_HALTED is from KVM_MP_STATE_RUNNABLE? > > > > See Paolo's table, it is. So why fix a race which should not be > > happening in the first place. > > The bad transition happens exactly because of the race. > Are you saying you prefer the solution with cmpxchg? > > Paolo
Vcpu should only invoke kvm_emulate_halt if it has been through a KVM_MP_STATE_UNINITIALIZED -> KVM_MP_STATE_INIT_RECEIVED -> KVM_MP_STATE_SIPI_RECEIVED -> KVM_MP_STATE_RUNNABLE transition. If it has been through that, how can a KVM_MP_STATE_INIT_RECEIVED be overwritten? That is, KVM_MP_STATE_RUNNABLE (precondition for kvm_emulate_halt) is only reachable if KVM_MP_STATE_INIT_RECEIVED/KVM_MP_STATE_SIPI_RECEIVED have not been overwritten. The point i'm trying to make is it appears the symptom is being fixed with the proposed patch, not the root cause (which, if the reasoning above is correct, is somewhere in nVMX code). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
