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

Re: [Xen-devel] One shared memory read/write issue between 2 different domains



Hi, 

At 17:39 +0800 on 25 May (1306345173), chunjie_zhu@xxxxxxxxxxxxxxxxx wrote:
> I code one ring buffer by myself for 2 domains to transmit data, one
> domain is producer, and the other is consumer. I do not use the ring
> buffer defined in ??include/xen/interface/io/ring.h??.

Why not?  That one has had a lot of testing and debugging.

> Just like the ring buffer provided by xen, I also use 2 pointers for
> producer and consumer, separately. To ensure memory access order is
> consistent, I use memory barrier between memory store/load operation
> and pointer update operation.
> 
> The transmitted data contains 2 parts, one is header, and the other is
> payload. Each time, one domain transmits the header first, and then
> the payload is sent out.
> 
> Each time I can get right header at the consumer side, however,
> sometimes, the data I get at the consumer side contains part of
> invalid information.
> 
> Could you please give me some suggestion on this issue?

Hard to say from just this description, but probably you're missing
either a hardware memory barrier or a compiler one.   Either that or
something in the rest of your code is corrupting the rings. 

Try comparing your code very carefully to the existing, working ring
buffer code.

> [Other Questions]
> 
> 1.  Is it reasonable to use spin lock to protect shared memory between
> 2 different domains?

It's probably not a great idea.  You have to worry about what happens if
one of the domains crashes while holding the lock, for example.

> 2.  Previously I use one atomic variable to do the synchronization
> between producer and consumer, however, sometimes I cannot get correct
> header at the consumer side. Is it one known-issue?

Again, you're probably missing a compiler barrier.  AIUI, updates to
atomic variables are only guaranteed not to be reordered WRT other write
of the _same_ variable.

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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