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

[Zach Pfeffer]

Joerg Roedel wrote:
> On Fri, Jul 02, 2010 at 12:09:02AM -0700, Zach Pfeffer wrote:
>> Hari Kanigeri wrote:
>>>> He demonstrated the usage of his code in one of the emails he sent out
>>>> initially. Did you go over that, and what (or how many) step would you
>>>> use with the current code to do the same thing?
>>> -- So is this patch set adding layers and abstractions to help the User ?
>>>
>>> If the idea is to share some memory across multiple devices, I guess
>>> you can achieve the same by calling the map function provided by iommu
>>> module and sharing the mapped address to the 10's or 100's of devices
>>> to access the buffers. You would only need a dedicated virtual pool
>>> per IOMMU device to manage its virtual memory allocations.
>> Yeah, you can do that. My idea is to get away from explicit addressing
>> and encapsulate the "device address to physical address" link into a
>> mapping.
> 
> 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. 

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.