Re: [PATCH v2] KVM: x86: Convert INIT and SIPI signals into synchronously handled requests

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3083 bytes --]

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@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.kiszka@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.
>>
>> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]