Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG.

[Peter Maydell]

On 11 August 2015 at 10:22, Benjamin Herrenschmidt
<address@hidden> wrote:
> On Tue, 2015-08-11 at 08:54 +0100, Alex Bennée wrote:
>>
>> > How do you handle the memory model ? IE , ARM and PPC are OO while x86
>> > is (mostly) in order, so emulating ARM/PPC on x86 is fine but emulating
>> > x86 on ARM or PPC will lead to problems unless you generate memory
>> > barriers with every load/store ..
>>
>> This is the next chunk of work. We have Alvise's LL/SC patches which
>> allow us to do proper emulation of ARMs Load/store exclusive behaviour
>> and any weak order target will have to use such constructs.
>
> God no ! You don't want to use ll/sc for dealing with weak ordering, you
> want to use barriers... ll/sc will allow you to deal with front-end
> things such as atomic inc/dec etc...

Agreed. ll/sc is atomicity, not ordering. (Conversely, barriers and
load-acquire/store-release are ordering, not atomicity...)

>> Currently the plan is to introduce a barrier TCG op which will translate
>> to the strongest backend barrier available.
>
> I would advocate at least two barriers, full barrier and write barrier,
> so at least when emulating ARM or PPC on x86, we don't actually send
> fences on every load/stores.

Is it possible in some of these combinations to use the load-acquire
and store-release instructions rather than explicit barriers?
(ARMv8 has those, which I think should be slightly less heavyweight
than explicit barriers everywhere, if the semantics line up.)

thanks
-- PMM