On 2012-07-06 09:46, liu ping fan wrote: > On Thu, Jul 5, 2012 at 7:58 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: >> On 2012-07-05 13:02, liu ping fan wrote: >>> On Thu, Jul 5, 2012 at 6:16 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: >>>> On 2012-07-05 12:10, liu ping fan wrote: >>>>> On Thu, Jul 5, 2012 at 2:46 PM, Jan Kiszka <jan.kiszka@xxxxxx> 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 <pingfank@xxxxxxxxxxxxxxxxxx> >>>>>>> --- >>>>>>> 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(). There is no difference in this scenario as well: the vcpu is waiting on a condvar for the initial kick-off and will synchronize with the main thread via the global mutex. When in doubt, try using a debugger. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html