Re: [patch] x86_*fence replaced by membar_ops(3)

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Manuel Bouyer wrote:
> I guess one day we'll want to change that. We want to make a difference between
> barrier private to the kernel and barriers used in foreing interfaces
> (Xen, or hardware drivers)
>
> > Why should the fences be any different than their membar_ops(3) 
> > equivalent here? In Xen drivers, there is no DMA, we are just bouncing 
> > data back and forth through shared pages. From my PoV, the membar_ops do 
> > make sense in this case as synchronisation primitives.
>
> This is in some sense equivalent to a DMA. It's not a PCI adapter which is
> accessing the data but the reader/writer is still accessing data
> in an asynchronous way from the kernel POW.

Okay, I did not understand the membar_ops(3) API that way. I thought it 
was a general purpose API for memory fences, without distinction of the 
underlying mechanisms (inter or intra synchronisation).

I get the point though, it does not make sense to keep the lock prefixes 
for UP x86 systems, except for adding extra overhead with no real gain 
(except maybe for LOCKDEBUG). Which is bad when using the same ones for DMA.

> > What should I do? Drop it for the x86 generic bus code, and keep it for 
> > the Xen drivers?
>
> No, membar_ops won't work for bus_dma/bus_space either. membar_ops are patched
> to be NOP on UP kernels, still they're needed for interfaces with 
> devices.

Hmm, I was not really clear on that one: I just meant to keep the 
membar_ops(3) routines for the xennet, xbd and xencons drivers: since we 
do not patch the LOCK prefix for UP Xen domains, they are close to the 
x86_*fence() ones.

I will just handle it the other way around. I'll keep the x86 MD fences 
and replace the ones inside Xen with their xen_[rw]mb() equivalents.

Any consideration on this one though:

http://www.netbsd.org/~jym/if_xennet_xenbus.c.diff

Is it really needed to have load-before-load ordering here? If we issue 
the hypercall, that will be a barrier anyway, and the RING macros from 
Xen do implement barrier for notify, so...

Thanks to all.

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost