Re: x86 bus_dmamap_sync

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

On Sat, Oct 28, 2017 at 01:35:02AM +0000, Taylor R Campbell wrote:
> > Date: Fri, 27 Oct 2017 23:08:23 +0000
> > From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
> > 
> > As noted by Mouse in a thread elsewhere, it looks like the LFENCE in
> > x86's bus_dmamap_sync in the POSTREAD case is in the wrong place.
> 
> Correction: Since yamt@ committed a fix for PR 21665 in 2004, there
> has been an LFENCE (or a stronger serializing instruction, on i386) in
> bus_dmamap_sync proper, in the POSTREAD case, _before_ calling the
> internal _bus_dmamap_sync logic.  So now I am puzzled by the LFENCE
> and MFENCE that bouyer@ added back in 2008 for PR 38935 -- it seems to
> me MFENCE is unnecessary for PREWRITE/POSTWRITE, LFENCE is not enough
> for PREREAD which I think needs an MFENCE, and a second LFENCE for
> POSTREAD is redundant.
> 
> I've attached a patch with a detailed comment explaining exactly what
> ordering of loads and stores I believe we need in each case, and the
> weakest x86 memory barrier that is needed to guarantee that ordering.
> The summary that I've provisionally convinced myself of is:
> 
> [Pre-DMA: driver is about to issue store to device register to
> initiate DMA transfer.]

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.

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