Re: x86 bus_dmamap_sync
Taylor R Campbell <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.x86-64,gmane.os.netbsd.ports.i386 |
|---|---|
| Message-ID | <[email protected]> |
> Date: Sat, 28 Oct 2017 17:40:48 +0200 > From: Manuel Bouyer <[email protected]> > > 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? 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. My goal here is mainly to document (a) what the ordering costraints we need are, and (b) how they are satisfied by whatever we issue on x86, so that the next person to come around and get confused by the placement of fences will be able to easily assess the code's correctness.