linux-kernel - Re: [PATCH] OMAP: iommu flush page table entries from L1 and L2 cache

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: <20110419130201.GA24972@n2100.arm.linux.org.uk>
Date:	Tue, 19 Apr 2011 14:02:01 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Kyungmin Park <kmpark@...radead.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Fernando Guzman Lugo <fernando.lugo@...com>,
	Tony Lindgren <tony@...mide.com>,
	Hiroshi DOYU <Hiroshi.DOYU@...ia.com>,
	linux-kernel@...r.kernel.org,
	Andrzej Pietrasiewicz <andrzej.p@...sung.com>,
	Ramesh Gupta <grgupta@...com>, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH] OMAP: iommu flush page table entries from L1 and L2
	cache

On Tue, Apr 19, 2011 at 09:35:56PM +0900, Kyungmin Park wrote:
> On Tue, Apr 19, 2011 at 9:01 PM, Arnd Bergmann <arnd@...db.de> wrote:
> > On Tuesday 19 April 2011, Kyungmin Park wrote:
> >> On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann <arnd@...db.de> wrote:
> >> > On Monday 18 April 2011, Kyungmin Park wrote:
> >> >> On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann <arnd@...db.de> wrote:
> >> >> >
> >> >> > One missing piece is still a way for a platform to provide both
> >> >> > the iommu and the dma-mapping API in a unified driver. Right now,
> >> >> > you have to export both interface for a generic solution.
> >> >>
> >> >> Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU
> >> >> implementation into mm, but MM did't accept it.
> >> >
> >> > I'm confused. What do you mean with MM?
> >> linux/mm, Memory Management.
> >
> > I'm still confused. What were you suggesting to merge in there?
> > Do you have a link to a mailing list discussion?
> 
> First, Zach Pfeffer <zpfeffer@...eaurora.org> sent the patch
> https://patchwork.kernel.org/patch/108736/
> 
> Second, Michal tried it.
> http://lkml.org/lkml/2010/9/6/41
> 
> http://lwn.net/Articles/403643/
> https://patchwork.kernel.org/patch/157451/

This shows why ARM is in such a problem.  People love to create new
frameworks and infrastructure where they find existing stuff lacking,
rather than looking at what other architectures do and adapt.

As I'm sure has already mentioned, the kernel already has support for
IOMMUs in the DMA path with several non-ARM architectures, and this
support is managed through the existing DMA API.

When you want a device behind an IOMMU to perform DMA, the driver
uses the DMA API in the standard way as if there was no IOMMU there.
As part of the DMA API, particularly the SG list part, the DMA API
is allowed to coalesce the SG entries together if it can arrange
the IOMMU mappings to achieve a continguous mapping for the device.
Remember, dma_map_sg() is allowed to return _fewer_ entries in the
scatterlist than was passed to it for this very purpose.

In order to transition ARM over to this, we need to modify the
scatterlist structure by enabling CONFIG_NEED_SG_DMA_LENGTH.  We
then need to arrange for the DMA API to have the hooks _both_ into
the DMA cache coherency code (to ensure that the data hits memory)
and the IOMMU code (this part is missing from ARM.)  The current
abstractions in the generic header files don't allow for this.

I don't believe there's any need for any major new framework - and I
don't think I'm alone in thinking that, especially as this point has
been raised more than once when this framework has been submitted.

I see no reason why ARM should be any different from other architectures
which have IOMMUs, and I don't see why ARM should have to invent a whole
new framework to handle IOMMUs.  And I see no explanation why the
existing hooks are unsuitable - at least as the _initial_ starting point.

So, can you please explain why your IOMMU code can not be hidden behind
the DMA API.  (Please omit any complaints about the mechanics of hooking
it in there, such things are solvable.)

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