Subject: Re: CVS commit: src/sys/arch/xen/xen
To: Lennart Augustsson <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 03/27/2005 13:30:48
On Sun, Mar 27, 2005 at 01:23:20AM +0100, Lennart Augustsson wrote:
> >I think we want a MI function to stop the processor from reordering
> >instructions too. There is potentially a similar problem in the esiop(4)
> >driver than the one I had with xen. I could abuse bus_space_barrier()
> >for this but it's not quite right either.
> >If we don't want the compiler to reorder instructions, I don't think we
> >to CPU to do it.
> You may want to disallow the compiler to reorder, but allow the CPU to.
> E.g., when programming with threads on a single CPU. The CPU reordering
> (on an x86) never changes how the processor sees the memory if it is the
> only client of the memory.
Sure, this is also why I didn't change all __insn_barrier() to x86_lfence()
in xen/. But even on single-CPU systems you need to dissalow the CPU
reordering, for example when talking with a device.
> So I think there is a case for both. And yes, of course we want MI ways
> of doing it. There is a whole range of possible fences one can imagine
> and they carry different costs depending on the platform.
Then we badly need to define theses, yes. And maybe refine the
bus_space_barrier() too ? From sparc64/bus.h:
* We have a bit of a problem with the bus_space_barrier()
* interface. It defines a read barrier and a write barrier
* which really don't map to the 7 different types of memory
* barriers in the SPARC v9 instruction set.
So just "BUS_SPACE_BARRIER_READ/WRITE" isn't enouth :)
Manuel Bouyer <firstname.lastname@example.org>
NetBSD: 26 ans d'experience feront toujours la difference