Re: x86 bus_dmamap_sync

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Oct 28, 2017 at 04:57:41PM +0000, Taylor R Campbell wrote:
> > Date: Sat, 28 Oct 2017 17:40:48 +0200
> > From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
> > 
> > Note that PR 38935 is about memory read/writes *only*, no read/write
> > to device registers happens here. This is common in modern DMA devices
> > which polls for command descriptors in memory and update descriptors in
> > memory in normal operation (think of it as a asymetric MP).
> > So the problem is not that memory is up to date before a device
> > register read/write, but really that the memory is updated or read
> > in order (without e.g. write coalescing or prefetch).
> > I'm not sure what you propose guarantees this.
> 
> Can you be more specific?  How is a device register read/write
> different from a command descriptor read/write as far as the CPU is
> concerned in the order of loads and stores it issues on the system bus?

It's been a while since I looked at this (but it fixed a real bug I
could reproduce). 

> 
> I said `device register' to give an example of what the load or store
> we need to order is, but unless I'm terribly confused, the *FENCE
> instructions impose ordering on the loads and stores the CPU sends to
> the system bus whether they're destined for device registers or main
> memory.

yes, that's the point.
But I'm not sure that without *fence insctructions, two writes to the
same location (or close locations) will be seen as two writes on the memory
side.
You propose to remove fence operation for *WRITE operation because
load vs store will always happen in program order.
But the problem is with store vs store.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--