From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] cpu: smp_wmb before lauching cpus. Date: Thu, 05 Jul 2012 13:58:14 +0200 Message-ID: <4FF58156.9050601@siemens.com> References: <1341454689-8129-1-git-send-email-qemulist@gmail.com> <4FF53856.6030901@web.de> <4FF56988.8060207@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "qemu-devel@nongnu.org" , Anthony Liguori , "kvm@vger.kernel.org" To: liu ping fan Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 2012-07-05 13:02, liu ping fan wrote: > On Thu, Jul 5, 2012 at 6:16 PM, Jan Kiszka wrote: >> On 2012-07-05 12:10, liu ping fan wrote: >>> On Thu, Jul 5, 2012 at 2:46 PM, Jan Kiszka 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 >>>>> --- >>>>> 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. Thanks, Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmkhX-0005bl-IR for qemu-devel@nongnu.org; Thu, 05 Jul 2012 07:58:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmkhQ-00048j-MZ for qemu-devel@nongnu.org; Thu, 05 Jul 2012 07:58:27 -0400 Received: from david.siemens.de ([192.35.17.14]:30284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmkhQ-00048P-Dd for qemu-devel@nongnu.org; Thu, 05 Jul 2012 07:58:20 -0400 Message-ID: <4FF58156.9050601@siemens.com> Date: Thu, 05 Jul 2012 13:58:14 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1341454689-8129-1-git-send-email-qemulist@gmail.com> <4FF53856.6030901@web.de> <4FF56988.8060207@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] cpu: smp_wmb before lauching cpus. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: "qemu-devel@nongnu.org" , Anthony Liguori , "kvm@vger.kernel.org" On 2012-07-05 13:02, liu ping fan wrote: > On Thu, Jul 5, 2012 at 6:16 PM, Jan Kiszka wrote: >> On 2012-07-05 12:10, liu ping fan wrote: >>> On Thu, Jul 5, 2012 at 2:46 PM, Jan Kiszka 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 >>>>> --- >>>>> 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. Thanks, Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux