linux-kernel - Re: [RFC 1/3 v3] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20100714201149.GA14008@codeaurora.org>
Date:	Wed, 14 Jul 2010 13:11:49 -0700
From:	Zach Pfeffer <zpfeffer@...eaurora.org>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	linux@....linux.org.uk, ebiederm@...ssion.com,
	linux-arch@...r.kernel.org, dwalker@...eaurora.org, mel@....ul.ie,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, andi@...stfloor.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device
 memory management

On Wed, Jul 14, 2010 at 10:59:38AM +0900, FUJITA Tomonori wrote:
> On Tue, 13 Jul 2010 05:14:21 -0700
> Zach Pfeffer <zpfeffer@...eaurora.org> wrote:
> 
> > > You mean that you want to specify this alignment attribute every time
> > > you create an IOMMU mapping? Then you can set segment_boundary_mask
> > > every time you create an IOMMU mapping. It's odd but it should work.
> > 
> > Kinda. I want to forget about IOMMUs, devices and CPUs. I just want to
> > create a mapping that has the alignment I specify, regardless of the
> > mapper. The mapping is created on a VCM and the VCM is associated with
> > a mapper: a CPU, an IOMMU'd device or a direct mapped device.
> 
> Sounds like you can do the above with the combination of the current
> APIs, create a virtual address and then an I/O address.
> 

Yes, and that's what the implementation does - and all the other
implementations that need to do this same thing. Why not solve the
problem once?

> The above can't be a reason to add a new infrastructure includes more
> than 3,000 lines.

Right now its 3000 lines because I haven't converted to a function
pointer based implementation. Once I do that the size of the
implementation will shrink and the code will act as a lib. Users pass
buffer mappers and the lib will ease the management of of those
buffers.

>  
> 
> > > Another possible solution is extending struct dma_attrs. We could add
> > > the alignment attribute to it.
> > 
> > That may be useful, but in the current DMA-API may be seen as
> > redundant info.
> 
> If there is real requirement, we can extend the DMA-API.

If the DMA-API contained functions to allocate virtual space separate
from physical space and reworked how chained buffers functioned it
would probably work - but then things start to look like the VCM API
which does graph based map management.

> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>
--
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/