From: "Alex Bennée" <alex.bennee@linaro.org>
To: Pranith Kumar <bobby.prani@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>,
"open list:All patches CC here" <qemu-devel@nongnu.org>,
Sergey Fedorov <serge.fdrv@gmail.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [RFC v3 PATCH 14/14] target-i386: Generate fences for x86
Date: Tue, 21 Jun 2016 19:25:08 +0100 [thread overview]
Message-ID: <87twgmqu0r.fsf@linaro.org> (raw)
In-Reply-To: <CAJhHMCA0_UgwVyx2DdhrAmEpXsOPs5TaqXcuJW26LdAxngeHZg@mail.gmail.com>
Pranith Kumar <bobby.prani@gmail.com> writes:
> On Tue, Jun 21, 2016 at 1:54 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 21 June 2016 at 18:28, Pranith Kumar <bobby.prani@gmail.com> 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
next prev parent reply other threads:[~2016-06-21 18:25 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160618040343.19517-1-bobby.prani@gmail.com>
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 01/14] Introduce TCGOpcode for memory barrier Pranith Kumar
2016-06-20 21:21 ` Sergey Fedorov
2016-06-21 14:52 ` Pranith Kumar
2016-06-21 15:09 ` Alex Bennée
2016-06-21 18:06 ` Pranith Kumar
2016-06-22 15:50 ` Sergey Fedorov
2016-06-21 7:30 ` Paolo Bonzini
2016-06-21 18:04 ` Alex Bennée
2016-06-21 18:09 ` Pranith Kumar
2016-06-21 18:23 ` Alex Bennée
2016-06-21 19:40 ` Richard Henderson
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 02/14] tcg/i386: Add support for fence Pranith Kumar
2016-06-21 7:24 ` Paolo Bonzini
2016-06-22 16:25 ` Alex Bennée
2016-06-22 16:49 ` Richard Henderson
2016-06-22 18:18 ` Alex Bennée
2016-06-18 4:03 ` [RFC v3 PATCH 03/14] tcg/aarch64: " Pranith Kumar
2016-06-18 4:03 ` [Qemu-devel] " Pranith Kumar
2016-06-23 16:18 ` Alex Bennée
2016-06-23 16:18 ` [Qemu-devel] " Alex Bennée
2016-06-23 16:50 ` Richard Henderson
2016-06-23 16:50 ` [Qemu-devel] " Richard Henderson
2016-06-23 19:58 ` Alex Bennée
2016-06-23 19:58 ` [Qemu-devel] " Alex Bennée
2016-06-18 4:03 ` [RFC v3 PATCH 04/14] tcg/arm: " Pranith Kumar
2016-06-18 4:03 ` [Qemu-devel] " Pranith Kumar
2016-06-23 16:30 ` Alex Bennée
2016-06-23 16:30 ` [Qemu-devel] " Alex Bennée
2016-06-23 16:49 ` Richard Henderson
2016-06-23 16:49 ` [Qemu-devel] " Richard Henderson
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 05/14] tcg/ia64: " Pranith Kumar
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 06/14] tcg/mips: " Pranith Kumar
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 07/14] tcg/ppc: " Pranith Kumar
2016-06-22 19:50 ` Sergey Fedorov
2016-06-22 20:21 ` Richard Henderson
2016-06-22 20:27 ` Sergey Fedorov
2016-06-23 14:42 ` Sergey Fedorov
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 08/14] tcg/s390: " Pranith Kumar
2016-06-21 7:26 ` Paolo Bonzini
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 09/14] tcg/sparc: " Pranith Kumar
2016-06-22 19:56 ` Sergey Fedorov
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 10/14] tcg/tci: " Pranith Kumar
2016-06-22 19:57 ` Sergey Fedorov
2016-06-22 20:25 ` Richard Henderson
2016-06-22 20:28 ` Sergey Fedorov
2016-06-18 4:03 ` [RFC v3 PATCH 11/14] target-arm: Generate fences in ARMv7 frontend Pranith Kumar
2016-06-18 4:03 ` [Qemu-devel] " Pranith Kumar
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 12/14] target-alpha: Generate fence op Pranith Kumar
2016-06-18 4:03 ` [RFC v3 PATCH 13/14] aarch64: Generate fences for aarch64 Pranith Kumar
2016-06-18 4:03 ` [Qemu-devel] " Pranith Kumar
2016-06-24 16:17 ` Alex Bennée
2016-06-24 16:17 ` [Qemu-devel] " Alex Bennée
2016-06-18 4:03 ` [Qemu-devel] [RFC v3 PATCH 14/14] target-i386: Generate fences for x86 Pranith Kumar
2016-06-18 5:48 ` Richard Henderson
2016-06-20 15:05 ` Pranith Kumar
2016-06-21 7:28 ` Paolo Bonzini
2016-06-21 15:57 ` Richard Henderson
2016-06-21 16:12 ` Paolo Bonzini
2016-06-21 16:23 ` Richard Henderson
2016-06-21 16:33 ` Paolo Bonzini
2016-06-21 17:28 ` Pranith Kumar
2016-06-21 17:54 ` Peter Maydell
2016-06-21 18:03 ` Pranith Kumar
2016-06-21 18:25 ` Alex Bennée [this message]
2016-06-22 11:18 ` Sergey Fedorov
2016-06-18 4:08 ` [Qemu-devel] [RFC v3 PATCH 00/14] tcg: Add fence gen support Pranith Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87twgmqu0r.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=bobby.prani@gmail.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=serge.fdrv@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.