Re: [kvm-unit-tests PATCH v5 11/11] new: arm/barrier-test for memory barriers

From: alvise rigo <a.rigo@virtualopensystems.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: mttcg@listserver.greensocs.com,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Andrew Jones" <drjones@redhat.com>,
	"Claudio Fontana" <claudio.fontana@huawei.com>,
	kvm@vger.kernel.org,
	"Alexander Spyridakis" <a.spyridakis@virtualopensystems.com>,
	"Mark Burton" <mark.burton@greensocs.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"KONRAD Frédéric" <fred.konrad@greensocs.com>
Subject: Re: [kvm-unit-tests PATCH v5 11/11] new: arm/barrier-test for memory barriers
Date: Mon, 3 Aug 2015 18:46:30 +0200	[thread overview]
Message-ID: <CAH47eN1i56z9J4pDH0LoCt+Mu2v=yUtr+AQvX1szJbFcZGyDmw@mail.gmail.com> (raw)
In-Reply-To: <87mvy8l5kt.fsf@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

On Mon, Aug 3, 2015 at 6:06 PM, Alex Bennée <alex.bennee@linaro.org> wrote:

>
> alvise rigo <a.rigo@virtualopensystems.com> writes:
>
> > On Mon, Aug 3, 2015 at 12:30 PM, Alex Bennée <alex.bennee@linaro.org>
> wrote:
> >>
> >> alvise rigo <a.rigo@virtualopensystems.com> writes:
> >>
> >>> Hi Alex,
> >>>
> >>> Nice set of tests, they are proving to be helpful.
> >>> One question below.
> >>>
> <snip>
> >>>
> >>> Why are we calling these last two instructions with the 'eq' suffix?
> >>> Shouldn't we just strex r1, r0, [sptr] and then cmp r1, #0?
> >>
> >> Possibly, my armv7 is a little rusty. I'm just looking at tweaking this
> >> test now so I'll try and clean that up.
>
> Please find the updated test attached. I've also included some new test
> modes. In theory the barrier test by itself should still fail but it
>

Thanks, I will check them out.

> passes on real ARMv7 as well as TCG. I'm trying to run the test on a
> heavier core-ed ARMv7 to check. I suspect we get away with it on
> ARMv7-on-x86_64 due to the strong ordering of the x86.

> The "excl" and "acqrel" tests now run without issue (although again
> plain acqrel semantics shouldn't stop a race corrupting shared_value).

I suppose that, in order to have some race conditions due to a lack of a
proper emulation of barriers and acqrel instructions, we need a test that
does not involve atomic instructions at all, to reduce the emulation
overhead as much as possible.
Does this sound reasonable?

>
> I'll tweak the v8 versions of the test tomorrow.
>
> --
> Alex Bennée
>
>

[-- Attachment #2: Type: text/html, Size: 2842 bytes --]