Re: [Qemu-devel] [PATCH] cpu: smp_wmb before lauching cpus.

[liu ping fan]

On Thu, Jul 5, 2012 at 7:58 PM, Jan Kiszka <address@hidden> wrote:
> On 2012-07-05 13:02, liu ping fan wrote:
>> On Thu, Jul 5, 2012 at 6:16 PM, Jan Kiszka <address@hidden> wrote:
>>> On 2012-07-05 12:10, liu ping fan wrote:
>>>> On Thu, Jul 5, 2012 at 2:46 PM, Jan Kiszka <address@hidden> wrote:
>>>>> On 2012-07-05 04:18, Liu Ping Fan wrote:
>>>>>> Vcpu state must be set completely before receiving INIT-IPI,SIPI
>>>>>>
>>>>>> Signed-off-by: Liu Ping Fan <address@hidden>
>>>>>> ---
>>>>>>  kvm.h |    1 +
>>>>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/kvm.h b/kvm.h
>>>>>> index 9c7b0ea..5b3c228 100644
>>>>>> --- a/kvm.h
>>>>>> +++ b/kvm.h
>>>>>> @@ -198,6 +198,7 @@ static inline void 
>>>>>> cpu_synchronize_post_init(CPUArchState *env)
>>>>>>  {
>>>>>>      if (kvm_enabled()) {
>>>>>>          kvm_cpu_synchronize_post_init(env);
>>>>>> +        smp_wmb();
>>>>>>      }
>>>>>>  }
>>>>>>
>>>>>>
>>>>>
>>>>> In theory, there should be no vcpu kick-off after this without some
>>>>> locking operations involved that imply barriers. Did you see real
>>>>
>>>> Yeah, but what if it is non-x86?
>>>
>>> The locking I'm referring to is arch independent.
>>>
>>>>> inconsistencies without this explicit one?
>>>
>>> Again: Did you see real issues or is this based on static analysis?
>>>
>> Just on  static analysis
>
> Then please describe - also for the changelog - at least one case in
> details where this is needed.
>
I dived into code. And yes, as you said, ACPI eject does involve some
locking operation. So the only thing left is for starting up.  There
seems no potential lock operation from cpu_synchronize_all_post_init()
to  resume_all_vcpus().
If correct, I will update this info for the changelog

Regards,
pingfa

> Thanks,
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> Corporate Competence Center Embedded Linux
>
>