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.kiszka@xxxxxxxxxxx> >>>> >>>> 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.kiszka@xxxxxxxxxxx> >>> >>> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
