Zach Pfeffer [off-list ref] writes:

On Wed, Jul 14, 2010 at 11:05:36PM +0100, Russell King - ARM Linux wrote:

quoted

On Wed, Jul 14, 2010 at 01:11:49PM -0700, Zach Pfeffer wrote:

quoted

If the DMA-API contained functions to allocate virtual space separate
from physical space and reworked how chained buffers functioned it
would probably work - but then things start to look like the VCM API
which does graph based map management.

Every additional virtual mapping of a physical buffer results in
additional cache aliases on aliasing caches, and more workload for
developers to sort out the cache aliasing issues.

What does VCM to do mitigate that?

The VCM ensures that all mappings that map a given physical buffer:
IOMMU mappings, CPU mappings and one-to-one device mappings all map
that buffer using the same (or compatible) attributes. At this point
the only attribute that users can pass is CACHED. In the absence of
CACHED all accesses go straight through to the physical memory.

The architecture of the VCM allows these sorts of consistency checks
to be made since all mappers of a given physical resource are
tracked. This is feasible because the physical resources we're
tracking are typically large.

On x86 this is implemented in the pat code, and could reasonably be
generalized to be cross platform.

This is controlled by HAVE_PFNMAP_TRACKING and with entry points
like track_pfn_vma_new.

Given that we already have an implementation that tracks the cached
vs non-cached attribute using the dma api.  I don't see that the
API has to change.  An implementation of the cached vs non-cached
status for arm and other architectures is probably appropriate.

It is definitely true that getting your mapping caching attributes
out of sync can be a problem.

Eric