qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH RFC 3/4] target-ppc: use atomic_cmpxchg for ld/st


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-ppc] [PATCH RFC 3/4] target-ppc: use atomic_cmpxchg for ld/st reservation
Date: Mon, 12 Sep 2016 19:15:32 +1000

On Mon, 2016-09-12 at 09:39 +0100, Alex Bennée wrote:
> 
> They are now in Richard's tcg-next queue
> 
> Message-Id: <address@hidden>
> Subject: [Qemu-devel] [PULL 00/18] tcg queued patches
> 
> All the backends support the new fence op, so far only ARM, Alpha and
> x86 emit the fence TCGOps as these are best added by someone who
> understands the frontend well.

Hrm, I should probably have a look ;-)

A bit swamped this week, I'll see what I can do.

Cheers,
Ben.

> > 
> > > 
> > > > 
> > > > 
> > > > I think this does matter, IIRC a kernel spin unlock on ppc is a
> > > > barrier + plain store, no load locked or store conditional.
> > > > 
> > > > > 
> > > > > > 
> > > > > > Specifically a racing store which happens to store the same
> > > > > > value
> > > > > > which was already in memory should clobber the reservation,
> > > > > > but won't
> > > > > > with this implementation.
> > > > > > 
> > > > > > I had a long discussion at KVM Forum with Emilio Costa
> > > > > > about this, in
> > > > > > which I discovered just how hard it is to strictly
> > > > > > implement
> > > > > > store-conditional semantics in terms of anything else.  So,
> > > > > > this is
> > > > > > probably a reasonable substitute, but we should note the
> > > > > > fact that
> > > > > > it's not 100%.
> > > > > 
> > > > > I will update the commit log.
> > > > > 
> > > > > Regards,
> > > > > Nikunj
> > > > > 
> > > 
> > > 
> 
> 
> --
> Alex Bennée



reply via email to

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