Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-05 Thread Paolo Bonzini
On 05/04/2016 05:35, Pranith Kumar wrote: > > You can find some information at > > https://bugzilla.redhat.com/show_bug.cgi?id=1142857 and > > This bug seems to be out-of-bounds. I get a message saying that the > bug has been restricted for internal development processes. Sorry, it's open now.

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-04 Thread Pranith Kumar
On Mon, Apr 4, 2016 at 1:03 PM, Paolo Bonzini wrote: >> >> Quoting >> http://www.inf.pucrs.br/~flash/progeng2/cppreference/w/cpp/atomic/atomic_thread_fencehtml.html: >> >> "Establishes memory synchronization ordering of non-atomic and relaxed >> atomic accesses" > > You can

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-04 Thread Paolo Bonzini
On 04/04/2016 19:03, Paolo Bonzini wrote: > I've looked at private email from that time and I was pointed to this > sentence in GCC's manual, which says the opposite: > > "Note that in the C++11 memory model, fences (e.g., > ‘__atomic_thread_fence’) take effect in combination with other

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-04 Thread Paolo Bonzini
On 04/04/2016 18:26, Pranith Kumar wrote: > Hi Paolo, > > On Mon, Apr 4, 2016 at 4:14 AM, Paolo Bonzini wrote: >> >> The issue is that atomic_thread_fence() only affects other atomic >> operations, while smp_rmb() and smp_wmb() affect normal loads and stores >> as well. >

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-04 Thread Pranith Kumar
Hi Paolo, On Mon, Apr 4, 2016 at 4:14 AM, Paolo Bonzini wrote: > > The issue is that atomic_thread_fence() only affects other atomic > operations, while smp_rmb() and smp_wmb() affect normal loads and stores > as well. That is different from what I understand what

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-04 Thread Paolo Bonzini
On 01/04/2016 22:35, Pranith Kumar wrote:; barrier(); }) > I could not really understand why we need to wrap the fence with > barrier()'s. There are three parts to my confusion. Let me ask one after the > other. > > On x86, __atomic_thread_fence(__ATOMIC_SEQ_CST) will generate an mfence >

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-01 Thread Pranith Kumar
Hi Alex, I have one question inline below. Alex Bennée writes: > The __atomic primitives have been available since GCC 4.7 and provide > a richer interface for describing memory ordering requirements. As a > bonus by using the primitives instead of hand-rolled functions we can > use tools such

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-01 Thread Alex Bennée
James Hogan writes: > Hi Alex, > > On Thu, Jan 28, 2016 at 10:15:17AM +, Alex Bennée wrote: >> The __atomic primitives have been available since GCC 4.7 and provide >> a richer interface for describing memory ordering requirements. As a >> bonus by using the

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-01 Thread Peter Maydell
On 1 April 2016 at 15:30, James Hogan wrote: > Hi Alex, > > On Thu, Jan 28, 2016 at 10:15:17AM +, Alex Bennée wrote: >> The __atomic primitives have been available since GCC 4.7 and provide >> a richer interface for describing memory ordering requirements. As a >>

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-04-01 Thread James Hogan
Hi Alex, On Thu, Jan 28, 2016 at 10:15:17AM +, Alex Bennée wrote: > The __atomic primitives have been available since GCC 4.7 and provide > a richer interface for describing memory ordering requirements. As a > bonus by using the primitives instead of hand-rolled functions we can > use tools

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-02-04 Thread Paolo Bonzini
On 29/01/2016 17:06, Alex Bennée wrote: > > Paolo Bonzini writes: > >> On 28/01/2016 11:15, Alex Bennée wrote: >>> +/* atomic_mb_read/set semantics map Java volatile variables. They are >>> + * less expensive on some platforms (notably POWER & ARM) than fully >>> + *

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-02-04 Thread Peter Maydell
On 4 February 2016 at 12:40, Paolo Bonzini wrote: > I don't know the exact feature test, and I think ARMv7's penalty is much > less because processors are slower, with a less deep pipeline and > usually not used in SMP configurations. Most v7 cores are SMP, and especially

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-01-29 Thread Alex Bennée
Paolo Bonzini writes: > On 28/01/2016 11:15, Alex Bennée wrote: >> +/* atomic_mb_read/set semantics map Java volatile variables. They are >> + * less expensive on some platforms (notably POWER & ARM) than fully >> + * sequentially consistent operations. >> + * >> + * As

[Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-01-28 Thread Alex Bennée
The __atomic primitives have been available since GCC 4.7 and provide a richer interface for describing memory ordering requirements. As a bonus by using the primitives instead of hand-rolled functions we can use tools such as the AddressSanitizer which need the use of well defined APIs for its

Re: [Qemu-devel] [PATCH v1 3/5] include/qemu/atomic.h: default to __atomic functions

2016-01-28 Thread Paolo Bonzini
On 28/01/2016 11:15, Alex Bennée wrote: > +/* atomic_mb_read/set semantics map Java volatile variables. They are > + * less expensive on some platforms (notably POWER & ARM) than fully > + * sequentially consistent operations. > + * > + * As long as they are used as paired operations they are