linux-kernel - Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100715011839.GA2239@codeaurora.org>
Date:	Wed, 14 Jul 2010 18:18:39 -0700
From:	Zach Pfeffer <zpfeffer@...eaurora.org>
To:	Joerg Roedel <joro@...tes.org>
Cc:	Hari Kanigeri <hari.kanigeri@...il.com>,
	Daniel Walker <dwalker@...eaurora.org>,
	Andi Kleen <andi@...stfloor.org>,
	Randy Dunlap <randy.dunlap@...cle.com>, mel@....ul.ie,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/