From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ta1ja-0000JO-HB for qemu-devel@nongnu.org; Sun, 18 Nov 2012 05:04:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ta1jX-0005Ds-Eq for qemu-devel@nongnu.org; Sun, 18 Nov 2012 05:04:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ta1jX-0005C3-6y for qemu-devel@nongnu.org; Sun, 18 Nov 2012 05:04:11 -0500 Message-ID: <50A8B290.7010105@redhat.com> Date: Sun, 18 Nov 2012 12:04:00 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1914486608.9887816.1352801368641.JavaMail.root@redhat.com> <50A368CD.1080002@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 1/8] atomic: introduce atomic operations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Peter Maydell , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Anthony Liguori , Jan Kiszka , Paolo Bonzini On 11/15/2012 09:47 AM, liu ping fan wrote: > On Wed, Nov 14, 2012 at 5:47 PM, Paolo Bonzini wr= ote: >> Il 14/11/2012 10:38, liu ping fan ha scritto: >>> On Tue, Nov 13, 2012 at 6:11 PM, Paolo Bonzini = wrote: >>>>>> Il 05/11/2012 06:38, Liu Ping Fan ha scritto: >>>>>>> From: Liu Ping Fan >>>>>>> >>>>>>> If out of global lock, we will be challenged by SMP in low level, >>>>>>> so need atomic ops. >>>>>>> >>>>>>> This file is a wrapper of GCC atomic builtin. >>>>>> >>>>>> I still object to this. >>>>>> >>>>>> I know it enforces type-safety, but it is incomplete. It doesn't >>>>> >>>>> Although it is incomplete, but the rest cases are rarely used. Lin= ux >>>>> faces such issue, and the "int" version is enough, so I think we ca= n >>>>> borrow experience from there. >>>> >>>> One of the two places that use __sync_* require 64-bit accesses. My >>> Yes, these two places are not easy to fix. >> >> Which shows that Linux's atomic_t is not suited for QEMU, in my opinio= n. >> >>>> RCU prototype required pointer-sized access, which you cannot make t= ype- >>> But I think that your RCU prototype should rely on atomic of CPU, not >>> gcc=91s atomic. >> >> What's the difference? gcc's atomic produces the same instructions as >> hand-written assembly (or should). >> > Probably I made a mistake here, in vhost, log =3D > __sync_fetch_and_and(from, 0) is used to fetch 64bits atomically in > the case 32bits qemu running on 64bits linux. Right? But how can > we read 32bits twice in atomic? Seem that no instruction like "_lock > xchg" for this ops. So I guess _sync_fetch_and_and() based on > something like spinlock. >=20 > And I think the broken issue is caused by vhost thread updates log, > while qemu read out it not atomicly, Right? For the log, 32-bit sync_fetch_and_and() is sufficient. We only need to ensure no bits are lost, we don't need 64-bit atomicity. --=20 error compiling committee.c: too many arguments to function