On 2013-03-06 22:50, Marcelo Tosatti wrote: > On Wed, Mar 06, 2013 at 10:39:27PM +0100, Jan Kiszka wrote: >> On 2013-03-06 22:30, Marcelo Tosatti wrote: >>> 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.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 >>> >>> The sentence "KVM_MP_STATE_INIT_RECEIVED overwritten by >>> kvm_emulate_halt" is contradictory, unless i miss something. >> >> http://thread.gmane.org/gmane.comp.emulators.kvm.devel/105638 >> >> Jan > > "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." > > > The scenario you describe is: > > vcpu0,bsp vcpu1 > > vcpu0->mp_state=KVM_MP_STATE_RUNNABLE This is not related to the race. > vcpu1->mp_state=KVM_MP_STATE_UNINIT Nor this. > > at __accept_apic_irq() > vcpu1->mp_state=KVM_MP_STATE_INIT_RECEIVED > kvm_emulate_halt > vcpu1->mp_state= > KVM_MP_STATE_HALTED Just these two sequences. vcpu0 need not be the BSP, any VCPU can send INIT at any time. > > > This is what the first sentence from the patch refers to, correct? The last part, yes. But there are more races due to the unsynchronized access to mp_state in lapic.c. I'm going to refactor my patch according to Gleb's and Paolos's suggestions, trying to keep the signals lapic-local, adding services to check for them and translate them into mp_state transitions over the target vcpu context. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
