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

[Alex Bennée]

alvise rigo <address@hidden> writes:

> On Mon, Aug 3, 2015 at 6:06 PM, Alex Bennée <address@hidden> wrote:
>
>>
>> alvise rigo <address@hidden> writes:
>>
>> > On Mon, Aug 3, 2015 at 12:30 PM, Alex Bennée <address@hidden>
>> wrote:
>> >>
>> >> alvise rigo <address@hidden> 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'm writing a "lockless" test now which uses just barriers and a postbox
style signal. But as I say I need to understand why the pure "barrier"
tests still works when it really shouldn't.

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

-- 
Alex Bennée