[RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

[Zach Pfeffer]

On Wed, Jul 14, 2010 at 09:34:03PM +0200, Joerg Roedel wrote:
> On Mon, Jul 12, 2010 at 10:21:05PM -0700, Zach Pfeffer wrote:
> > Joerg Roedel wrote:
> 
> > > The DMA-API already does this with the help of IOMMUs if they are
> > > present. What is the benefit of your approach over that?
> > 
> > The grist to the DMA-API mill is the opaque scatterlist. Each
> > scatterlist element brings together a physical address and a bus
> > address that may be different. The set of scatterlist elements
> > constitute both the set of physical buffers and the mappings to those
> > buffers. My approach separates these two things into a struct physmem
> > which contains the set of physical buffers and a struct reservation
> > which contains the set of bus addresses (or device addresses). Each
> > element in the struct physmem may be of various lengths (without
> > resorting to chaining). A map call maps the one set to the other.
> 
> Okay, thats a different concept, where is the benefit?

The benefit is that virtual address space and physical address space
are managed independently. This may be useful if you want to reuse the
same set of physical buffers, a user simply maps them when they're
needed. It also means that different physical memories could be
targeted and a virtual allocation could map those memories without
worrying about where they were. 

This whole concept is just a logical extension of the already existing
separation between pages and page frames... in fact the separation
between physical memory and what is mapped to that memory is
fundamental to the Linux kernel. This approach just says that arbitrary
long buffers should work the same way.