Re: [PATCHv2 1/5] mm: add coherence API for DMA to vmalloc/vmap areas

[James Bottomley <James.Bottomley@suse.de>]

On Sun, 2010-01-03 at 08:27 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-12-24 at 05:39 -0700, Matthew Wilcox wrote:
> > 
> > invalidates the processor cache for a given virtual address range
> > in the vmap area.  This API addresses the problem that the processor
> > may have performed speculative reads into its cache of the vmapped
> > area while I/O was occurring to the underlying physical pages.
> > 
> > Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
> 
> Interestingly, our DMA APIs in this regard are sub-optimal as they
> should provide 3 hooks, not 2.
> 
> Flush is good for ensuring dirty lines have been pushed out before an
> outgoing DMA.
> 
> But for incoming DMA it would be nice to properly split the 2 calls that
> may be needed on some archs, one before, one after the transfer. Sure,
> invalidate twice will "work" but the f will also be sub-optimal on some
> platforms depending on whether the platform is known to be able or not
> to speculatively load cache lines etc...
> 
> Maybe just a "before" vs. "after" argument ?
> 
> Also, the proposal goes contrary to most of our DMA APIs which don't
> actually expose the details of invalidate vs. flush but instead expose
> the direction of the transfer (both lack the above subtlety though).
> 
> Thoughts ?

Well, that's the result of the email thread.  XFS is poking deeply into
architectural issues by trying to do I/O on a vmap area.  I thought the
consensus was that if xfs wants to do that then it takes complete
responsibility for coherence rather than trying to hide it in a block
API.

James