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: <4C3BF7C1.9040904@codeaurora.org>
Date:	Mon, 12 Jul 2010 22:21:05 -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

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.
--
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/