> > In order to take full advantage of cache-coherent DVMA, the routines that
> > load the IOMMU page tables should changed to allocate DVMA addresses
> > that are congruent to kernel virtual addresses mapping the same physical
> > page(s).
> > 
> > I was looking at the extent_*() routines to assist with this, but it
> > doesn't seem to directly support this type of resource allocation.
> 
> We had to do this for the sun3x, since it has as an IOMMU as well.  Our
> solution was to use a resource map, rather than an extent map.

Yes, that sun3x code is derived from the akin sun4/sun4c code for
allocating DVMA addresses. (BTW. there's nothing the old `resource map'
code can do that the new extent code can't).

The problem with doing DVMA in the presence of a virtually indexed
cache that also implements a cache-coherency protocol (like the Hypersparc
does) is that it puts aliasing restrictions on the address used to do
a DVMA transaction.

Either you abide by that rule or you turn off the cache-bits for
DVMA-mapped pages (and do appropriate cache-flushing before/after
initiating a DVMA transfer).

Hence the need for doing the thing in the first quoted paragraph above,
if you want to take advantage of the hardware.

-pk