From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8Dna-0002eq-Rj for qemu-devel@nongnu.org; Wed, 01 Jun 2016 17:35:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8DnV-0003RZ-Qs for qemu-devel@nongnu.org; Wed, 01 Jun 2016 17:35:33 -0400 Received: from mail-qk0-x22c.google.com ([2607:f8b0:400d:c09::22c]:35642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8DnV-0003RU-MB for qemu-devel@nongnu.org; Wed, 01 Jun 2016 17:35:29 -0400 Received: by mail-qk0-x22c.google.com with SMTP id c140so22351802qke.2 for ; Wed, 01 Jun 2016 14:35:29 -0700 (PDT) Sender: Richard Henderson References: <20160531183928.29406-1-bobby.prani@gmail.com> <20160531183928.29406-2-bobby.prani@gmail.com> From: Richard Henderson Message-ID: <016450d7-f6b9-ef14-9ef0-96d78eb1ac5c@twiddle.net> Date: Wed, 1 Jun 2016 14:35:26 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 PATCH 01/13] Introduce TCGOpcode for memory barrier List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pranith Kumar Cc: "open list:All patches CC here" , =?UTF-8?Q?Alex_Benn=c3=a9e?= , Sergey Fedorov On 06/01/2016 11:43 AM, Pranith Kumar wrote: >> This is, IMO, confused. Either we should use the C++11 barrier types, or >> the Linux barrier types, but not both. > > This part of the design is still being fleshed out. The above listing > is all the kinds of barriers we can encounter during translation. May > be I am missing something, but C++11 and Linux barrier types have > higher level semantics which is difficult to infer at the instruction > level. Fair enough. > All we want to do here is map a barrier instruction from guest to a > barrier instruction on hist. This mapping is 1:1 if the host has > barrier instructions with matching semantics. Otherwise we generate a > multi-op instruction sequence. Some examples are: load acquire(ldar) > on ARM64 guest will map to dmb+load on ARMv7 target, store > fence(sfence) on x86 guest will map to dmb on ARMv7 target. Perhaps we should model this like the Sparc membar instruction, with individual bits for all combinations of Load x Store. One can then describe exactly what the target semantics are for each barrier. r~