From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33089) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8VVr-0007Zz-Rl for qemu-devel@nongnu.org; Thu, 02 Jun 2016 12:30:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8VVl-0007FY-Oh for qemu-devel@nongnu.org; Thu, 02 Jun 2016 12:30:26 -0400 Received: from mail-lf0-x241.google.com ([2a00:1450:4010:c07::241]:35721) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8VVl-0007Ey-BK for qemu-devel@nongnu.org; Thu, 02 Jun 2016 12:30:21 -0400 Received: by mail-lf0-x241.google.com with SMTP id q63so5649421lfi.2 for ; Thu, 02 Jun 2016 09:30:20 -0700 (PDT) References: <20160531183928.29406-1-bobby.prani@gmail.com> <20160531183928.29406-2-bobby.prani@gmail.com> From: Sergey Fedorov Message-ID: <57505F1A.3020808@gmail.com> Date: Thu, 2 Jun 2016 19:30:18 +0300 MIME-Version: 1.0 In-Reply-To: <20160531183928.29406-2-bobby.prani@gmail.com> Content-Type: text/plain; charset=windows-1252 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 , Richard Henderson , "open list:All patches CC here" Cc: serge.fdrv@linaro.org, alex.bennee@linaro.org On 31/05/16 21:39, Pranith Kumar wrote: > diff --git a/tcg/README b/tcg/README > index f4a8ac1..cfe79d7 100644 > --- a/tcg/README > +++ b/tcg/README > @@ -402,6 +402,23 @@ double-word product T0. The later is returned in two single-word outputs. > > Similar to mulu2, except the two inputs T1 and T2 are signed. > > +********* Memory Barrier support > + > +* mb <$arg> > + > +Generate a target memory barrier instruction to ensure memory ordering as being > +enforced by a corresponding guest memory barrier instruction. The ordering > +enforced by the backend may be stricter than the ordering required by the guest. > +It cannot be weaker. This opcode takes an optional constant argument if required > +to generate the appropriate barrier instruction. The backend should take care to > +emit the target barrier instruction only when necessary i.e., for SMP guests and > +when MTTCG is enabled. > + > +The guest translators should generate this opcode for all guest instructions > +which have ordering side effects. I think we need to extend TCG load/store instruction attributes to provide information about guest ordering requirements and leave this TCG operation only for explicit barrier instruction translation. > + > +Please see docs/atomics.txt for more information on memory barriers. > + > ********* 64-bit guest on 32-bit host support > > The following opcodes are internal to TCG. Thus they are to be implemented by > diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c > index f554b86..a6f01a7 100644 > --- a/tcg/tcg-op.c > +++ b/tcg/tcg-op.c > @@ -143,6 +143,12 @@ void tcg_gen_op6(TCGContext *ctx, TCGOpcode opc, TCGArg a1, TCGArg a2, > tcg_emit_op(ctx, opc, pi); > } > > +void tcg_gen_mb(TCGArg a) > +{ > + /* ??? Enable only when MTTCG is enabled. */ > + tcg_gen_op1(&tcg_ctx, INDEX_op_mb, 0); Yes, this could be a right place to check for MTTCG enabled and number of CPUs emulated. If we do it here, then we should adjust the documentation stating that the backend should take care of it. Kind regards, Sergey