From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuyjK-0003co-UF for qemu-devel@nongnu.org; Thu, 25 Mar 2010 21:52:58 -0400 Received: from [140.186.70.92] (port=60871 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuyjJ-0003bC-HU for qemu-devel@nongnu.org; Thu, 25 Mar 2010 21:52:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuyjI-0007JW-16 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 21:52:57 -0400 Received: from mail2.shareable.org ([80.68.89.115]:59181) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuyjH-0007JN-Ra for qemu-devel@nongnu.org; Thu, 25 Mar 2010 21:52:55 -0400 Date: Fri, 26 Mar 2010 01:52:52 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 00/10, v3] target-alpha improvements Message-ID: <20100326015252.GG19308@shareable.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org, aurelien@aurel32.net Richard Henderson wrote: > I don't see how any sort of emulation of cmpxchg/load-locked is working > for any currently enabled nptl target. I think how I've approached > handling load-locked for alpha is probably the easiest way. Slightly > better would be if TCG had a (set of) cmpxchg opcodes, which would have > the benefit of getting the virt->phys->host address (and segfault handling) > more correct. I've sort of totally ignored the faulting for now. I guess you are thinking to save the value loaded by load-locked, and use it as the "old" for host cmpxchg at target's store-conditional? I'm not sure if that will have the correct behaviour for all target architectures, where _any_ value written by another CPU during an ll/sc sequence will prevent the sequence from proceeding, including CPU #0 CPU #1 x <- load-locked(A) y <- load(B) x+1 -> store(A) y+1 -> store(B) x -> store(A) f(x,y) -> store-cond(A) Unless I made a mistake, the above cannot store f(x,y+1) into A, for any interleaving (assume strongly ordered memory or barriers), on machines where any store by another CPU breaks the condition. But on machines which implement store-cond by atomic-cmpxchg using the load-locked value, f(x,y+1) can be stored. It'll be fine when ll/sc are only used to provide single-word atomic calculations, but I'm not sure those are the only uses to which they are put by any code anywhere. E.g. if I remember rightly, there was some discussion of a planned unusual ll/sc use on the linux-arm list, which involved a second word, but the idea wasn't ever implemented. -- Jamie