qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: alvise rigo
Subject: Re: [Qemu-devel] [kvm-unit-tests PATCH v5 11/11] new: arm/barrier-test for memory barriers
Date: Mon, 3 Aug 2015 18:46:30 +0200



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'll tweak the v8 versions of the test tomorrow.

--
Alex Bennée



reply via email to

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