linux-kernel - Re: [RFC] mm: iommu: An API to unify IOMMU, CPU and device memory management

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: <20100627134401G.fujita.tomonori@lab.ntt.co.jp>
Date:	Sun, 27 Jun 2010 13:46:07 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	zpfeffer@...eaurora.org
Cc:	andi@...stfloor.org, mel@....ul.ie, dwalker@...eaurora.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: [RFC] mm: iommu: An API to unify IOMMU, CPU and device memory
 management

On Thu, 24 Jun 2010 23:48:50 -0700
Zach Pfeffer <zpfeffer@...eaurora.org> wrote:

> Andi Kleen wrote:
> > Zach Pfeffer <zpfeffer@...eaurora.org> writes:
> > 
> >> This patch contains the documentation for and the main header file of
> >> the API, termed the Virtual Contiguous Memory Manager. Its use would
> >> allow all of the IOMMU to VM, VM to device and device to IOMMU
> >> interoperation code to be refactored into platform independent code.
> > 
> > I read all the description and it's still unclear what advantage
> > this all has over the current architecture? 
> > 
> > At least all the benefits mentioned seem to be rather nebulous.
> > 
> > Can you describe a concrete use case that is improved by this code
> > directly?
> 
> Sure. On a SoC with many IOMMUs (10-100), where each IOMMU may have
> its own set of page-tables or share page-tables, and where devices
> with and without IOMMUs and CPUs with or without MMUS want to
> communicate, an abstraction like the VCM helps manage all conceivable
> mapping topologies. In the same way that the Linux MM manages pages
> apart from page-frames, the VCMM allows the Linux MM to manage ideal
> memory regions, VCMs, apart from the actual memory region.
> 
> One real scenario would be video playback from a file on a memory
> card. To read and display the video, a DMA engine would read blocks of
> data from the memory card controller into memory. These would
> typically be managed using a scatter-gather list. This list would be
> mapped into a contiguous buffer of the video decoder's IOMMU. The
> video decoder would write into a buffer mapped by the display engine's
> IOMMU as well as the CPU (if the kernel needed to intercept the
> buffers). In this instance, the video decoder's IOMMU and the display
> engine's IOMMU use different page-table formats.
> 
> Using the VCM API, this topology can be created without worrying about
> the device's IOMMUs or how to map the buffers into the kernel, or how
> to interoperate with the scatter-gather list. The call flow would would go:

Can you explain how you can't do the above with the existing API?


> The general point of the VCMM is to allow users a higher level API
> than the current IOMMU abstraction provides that solves the general
> mapping problem. This means that all of the common mapping code would
> be written once. In addition, the API allows all the low level details
> of IOMMU programing and VM interoperation to be handled at the right
> level.
> 
> Eventually the following functions could all be reworked and their
> users could call VCM functions.

There are more IOMMUs (e.g. x86 has calgary, gart too). And what is
the point of converting old IOMMUs (the majority of the below)? are
there any potential users of your API for such old IOMMUs?
--
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/