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

alvise rigo
2015-08-03T16:46:30Z

[-- 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 --]