[Top][All Lists]

[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: Alex Bennée
Subject: Re: [Qemu-devel] [RFC v3 PATCH 14/14] target-i386: Generate fences for x86
Date: Tue, 21 Jun 2016 19:25:08 +0100
User-agent: mu4e 0.9.17; emacs

Pranith Kumar <address@hidden> writes:

> On Tue, Jun 21, 2016 at 1:54 PM, Peter Maydell <address@hidden> wrote:
>> On 21 June 2016 at 18:28, Pranith Kumar <address@hidden> wrote:
>>> 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.
>> I vaguely recall an idea that you could avoid needing
>> explicit barriers by turning all the guest load/stores into
>> host load-acquire/store-release, but I have no idea whether
>> that's (a) actually true (b) any better than piles of
>> explicit barriers.
> Yes, this is true for ARMv8(not sure about ia64). The
> load-acquire/store-release operations are sequentially consistent to
> each other. But this does not work for ARMv7 and as you said... I
> think the cost here too is really prohibitive.

If the cost ends up being too prohibitive (as in -smp N runs slower and
slower) then we may just keep -accel tcg,thread=single the default for
that combination.

We need some hard numbers either way.

Alex Bennée

reply via email to

[Prev in Thread] Current Thread [Next in Thread]