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: 1652 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]