On Mon, Aug 13, 2012 at 5:41 PM, Mike Belopuhov <m...@crypt.org.ru> wrote: > On Mon, Aug 13, 2012 at 5:36 PM, Mike Belopuhov <m...@crypt.org.ru> wrote: >> On Mon, Aug 13, 2012 at 5:30 PM, Stefan Fritsch <stefan_frit...@genua.de> >> wrote: >>> On Monday 13 August 2012 17:07:41 you wrote: >>>> > * Note: the i386 does not currently require barriers, but we must >>>> > * provide the flags to MI code. >>>> > >>>> > This is not correct for virtio. We need a memory barrier. >>>> >>>> sure, copy it from amd64. >>> >>> OK. A slight complication: >>> >>> sfence/mfence/lfence do not exist on all i386 CPUs. sfence was introduced >>> with >>> SSE, [lm]fence with SSE2. This is not really a problem with the virtio >>> driver >>> because the virtualization extensions were introduced much later. But it may >>> be a problem with the rest of the i386 code. >>> >>> How do you normally handle this? Check during boot and set a pointer to the >>> function to be used and call that function pointer from bus_space_barrier()? >>> >> >> actually you might try this: >> >> http://nxr.netbsd.org/xref/src/sys/arch/x86/x86/bus_space.c#877 >> >> same as we do with bus_dmamap_sync on i386/amd64. > > but otherwise i think you should test the presense of the instruction > and set a function pointer somewhere in machdep.
by the way. you might actually want to use bus_dmamap_sync if the memory in question is shared with the host (DMA kind of).
