Re: [Xen-devel] [PATCH 2/3] xen/arm64: resync atomics and spinlock asm with Linux

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-07-30 at 10:45 +0100, Will Deacon wrote:
> On Tue, Jul 30, 2013 at 10:34:12AM +0100, Ian Campbell wrote:
> > On Mon, 2013-07-29 at 19:05 +0100, Will Deacon wrote:
> > > On Mon, Jul 29, 2013 at 05:13:02PM +0100, Ian Campbell wrote:
> > > > On Mon, 2013-07-29 at 17:02 +0100, Tim Deegan wrote:
> > > > > But I don't understand the new 'memory' clobbers around in this patch.
> > > > > Or rather, I don't understand why there are memory clobbers but not
> > > > > DMBs.
> > > 
> > > The acquire/release instructions imply half barriers, but GCC may still
> > > re-order instructions across them unless we include the memory clobber.
> > 
> > The instructions which Tim is querying patch the are
> > load/store-exclusive (ldxr,stxr) not acquire/release (ldaxr/stlxr et al)
> > ones. The a/r ones do indeed have implicit barriers but do the l/s-excl
> > do too?
> > 
> > The ARM ARM Tim quoted was the v7 version but I don't see anything in
> > the v8 docs which I have available (which I know are incomplete and may
> > well be out of date) which says anything about barriers (implicit or
> > otherwise) wrt the l/s-excl instructions. I do see stuff relating to the
> > a/r instructions having implicit barriers.
> 
> Ah sorry, should've looked more closely. This is basically because not all
> atomic operations in Linux imply barriers.
> 
> Take a look at Documentation/atomic_ops.txt and check whether it matches the
> semantics required by Xen.

Ohoo, I wasn't aware of that (it's not that surprising mind). Some
auditing of the Xen code may be required here!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel