lkml.org 
[lkml]   [2010]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
    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.


    \
     
     \ /
      Last update: 2010-07-15 03:21    [W:4.152 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site