Re: [Xen-devel] [PATCH 8/8] evtchn: add FIFO-based event channel hypercalls and port ops

[Tim Deegan <tim@xxxxxxx>]

At 14:38 +0000 on 20 Mar (1363790300), David Vrabel wrote:
> On 20/03/13 14:23, Tim Deegan wrote:
> > At 13:55 +0000 on 20 Mar (1363787704), Jan Beulich wrote:
> >>>>> On 20.03.13 at 14:42, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> >>> On 20/03/13 10:47, Jan Beulich wrote:
> >>>>>>> On 19.03.13 at 22:00, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> >>>>> +struct evtchn_fifo_queue {
> >>>>> +    volatile uint32_t *head; /* points into control block */
> >>>>
> >>>> I still think that explicit barriers are the way to go. Unless Linux'es
> >>>> view on this has changed, you'll have issues getting the Linux folks
> >>>> to accept this.
> >>>
> >>> This volatile can just be removed.  head is only written by Xen in one
> >>> place and it is immediately followed by a spin_unlock() which is a 
> >>> barrier.
> >>
> >> A release type barrier only, but that presumably is sufficient for
> >> the purposes here.
> > 
> > You might have to use an atomic_t or similar if the consumer might be
> > confused by partial updates.
> 
> I have assumed that reads and writes to 32-bit words are atomic on all
> interesting architectures.

True, but unless you explicitly tell it to, the compiler isn't required
to update a 32-bit variable using 32-bit operations, or to avoid
weird-looking intermediate values.  It seems unlikely that it would do
anything other than straightforwardly write the new value, but we've seen
compilers do some unlikely things. :)

Tim.

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