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

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



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.

David

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.