Port-xen archive

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

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

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:


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

Home | Main Index | Thread Index | Old Index