From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwptj-0006uw-Tu for qemu-devel@nongnu.org; Fri, 26 Aug 2011 02:28:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qwptj-0004lM-2q for qemu-devel@nongnu.org; Fri, 26 Aug 2011 02:28:11 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:53918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qwpti-0004lG-UA for qemu-devel@nongnu.org; Fri, 26 Aug 2011 02:28:11 -0400 Received: by vws17 with SMTP id 17so2976957vws.4 for ; Thu, 25 Aug 2011 23:28:10 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4E573CF5.2020609@redhat.com> Date: Fri, 26 Aug 2011 08:28:05 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20110826054008.GL2308@yookeroo.fritz.box> In-Reply-To: <20110826054008.GL2308@yookeroo.fritz.box> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Missing barriers in hw/virtio.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, agraf@suse.de, aik@ozlabs.ru, Paul 'Rusty' Russell , Benjamin Herrenschmidt On 08/26/2011 07:40 AM, David Gibson wrote: > Near the top of hw/virtio.c we have this: > > /* QEMU doesn't strictly need write barriers since everything runs in > * lock-step. We'll leave the calls to wmb() in though to make it > obvious for > * KVM or if kqemu gets SMP support. > * In any case, we must prevent the compiler from reordering the code. > * TODO: we likely need some rmb()/mb() as well. > */ > > #define wmb() __asm__ __volatile__("": : :"memory") > > > However, as far as I can tell when using both kvm and io-thread, the > assertion that barriers aren't necessary just isn't true. Although it > probably works on x86 with its strongly ordered model. > > We think we've hit a race due to this with kvm on POWER, described in > the forwarded message below. Adding a barrier fixes the problem. > Below we just stuck in a powerpc specific barrier which was useful as > proof of concept, but I'm not sure how to go about putting a proper, > architecture-appropriate barrier into this code. Yes, I think you are right. To get a full memory barrier you can add __sync_synchronize() and require GCC 4.2 or later (or Red Hat 4.1). Or we can import a library of atomic functions from e.g. liburcu, which will provide separate macros for mb()/rmb()/wmb(). Alternatively, we can define all of #define mb() __sync_synchronize() #define rmb() __sync_synchronize() #define wmb() __sync_synchronize() So that we can still differentiate at the source-code level, even though all the macros will emit full barriers. Paolo