From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8XZU-0008Q0-5o for qemu-devel@nongnu.org; Thu, 02 Jun 2016 14:42:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b8XZO-000804-TE for qemu-devel@nongnu.org; Thu, 02 Jun 2016 14:42:19 -0400 Received: from mail-yw0-x244.google.com ([2607:f8b0:4002:c05::244]:34454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b8XZO-000800-OW for qemu-devel@nongnu.org; Thu, 02 Jun 2016 14:42:14 -0400 Received: by mail-yw0-x244.google.com with SMTP id j74so8003806ywg.1 for ; Thu, 02 Jun 2016 11:42:14 -0700 (PDT) References: <20160531183928.29406-1-bobby.prani@gmail.com> <20160531183928.29406-2-bobby.prani@gmail.com> <57505F1A.3020808@gmail.com> From: Pranith Kumar In-reply-to: <57505F1A.3020808@gmail.com> Date: Thu, 02 Jun 2016 14:42:12 -0400 Message-ID: <87fusvbfgb.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain 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: Sergey Fedorov Cc: Richard Henderson , "open list:All patches CC here" , serge.fdrv@linaro.org, alex.bennee@linaro.org Sergey Fedorov writes: > 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. > Yes, I am working on adding flag argument to the TCG MemOp which indicates this. >> + >> +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. > I added the check in Patch 13. I will update the documentation to reflect this. Thanks, -- Pranith