On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote: > On 2013-03-06 07:12, 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? > > I think we are past that point in our discussion and should really > separate signal (INIT/SIPI) from state (INIT/SIPI_RECEIVED etc.). > > Jan
The sentence "KVM_MP_STATE_INIT_RECEIVED overwritten by kvm_emulate_halt" is contradictory, unless i miss something. The KVM_REQ_ solution is messy, should avoid introducing new request bits if possible. -- 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
