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:59 +0100, Will Deacon wrote:
> On Tue, Jul 30, 2013 at 10:55:01AM +0100, Ian Campbell wrote:
> > 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!
> 
> If you need overly strong barrier semantics (i.e. dmb(); op(); dmb()) then
> you could look at the GCC atomic builtins, which are fairly heavy on the
> barrier-front iirc.

Go tip, thanks. Xen's x86 background means it probably assumes some
fairly heavy barriers in some places but we aren't generally averse to
just fixing those where needed.

Ian.



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