[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v3 PATCH 14/14] target-i386: Generate fences for x
From: |
Pranith Kumar |
Subject: |
Re: [Qemu-devel] [RFC v3 PATCH 14/14] target-i386: Generate fences for x86 |
Date: |
Tue, 21 Jun 2016 13:28:25 -0400 |
On Tue, Jun 21, 2016 at 3:28 AM, Paolo Bonzini <address@hidden> wrote:
>
>
> On 18/06/2016 06:03, Pranith Kumar wrote:
>> Signed-off-by: Pranith Kumar <address@hidden>
>> ---
>> target-i386/translate.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/target-i386/translate.c b/target-i386/translate.c
>> index bf33e6b..32b0f5c 100644
>> --- a/target-i386/translate.c
>> +++ b/target-i386/translate.c
>> @@ -8012,13 +8012,17 @@ static target_ulong disas_insn(CPUX86State *env,
>> DisasContext *s,
>> || (prefixes & PREFIX_LOCK)) {
>> goto illegal_op;
>> }
>> + tcg_gen_mb(TCG_MO_ST_ST | TCG_BAR_SC);
>> break;
>> case 0xe8 ... 0xef: /* lfence */
>> + tcg_gen_mb(TCG_MO_LD_LD | TCG_BAR_SC);
>> + break;
>
> These are unnecessary. On the other hand, _each and every load_ must be
> followed by a LD_LD | LD_ST barrier, and each and every store must be
> preceded by a LD_ST | ST_ST barrier.
>
Reg. the second point, I did consider this situation of running x86 on
ARM where such barriers are necessary for correctness. But, I am
really apprehensive of the cost it will impose. I am not sure if there
are any alternative solutions to avoid generating barriers for each
memory operation, but it would be great if we could reduce them.
Thanks,
--
Pranith