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
