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]

Date:	Thu, 22 Jul 2010 09:13:53 -0700
From:	Zach Pfeffer <zpfeffer@...eaurora.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	alan@...rguk.ukuu.org.uk, randy.dunlap@...cle.com,
	dwalker@...eaurora.org, mel@....ul.ie,
	linux-arm-msm@...r.kernel.org, joro@...tes.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 3/3] mm: iommu: The Virtual Contiguous Memory Manager

On Thu, Jul 22, 2010 at 08:51:51AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 21, 2010 at 08:50:26PM -0700, Zach Pfeffer wrote:
> > On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
> > > On Tue, 13 Jul 2010 10:02:23 +0100
> > > 
> > > Zach Pfeffer said this new VCM infrastructure can be useful for
> > > video4linux. However, I don't think we need 3,000-lines another
> > > abstraction layer to solve video4linux's issue nicely.
> > 
> > Its only 3000 lines because I haven't converted the code to use
> > function pointers.
> 
> I don't understand - you've made this claim a couple of times.  I
> can't see how converting the code to use function pointers (presumably
> to eliminate those switch statements) would reduce the number of lines
> of code.
> 
> Please explain (or show via new patches) how does converting this to
> function pointers significantly reduce the number of lines of code.
> 
> We might then be able to put just _one_ of these issues to bed.

Aye. Its getting worked on. Once its done I'll push it.

> 
> > Getting back to the point. There is no API that can handle large
> > buffer allocation and sharing with low-level attribute control for
> > virtual address spaces outside the CPU.
> 
> I think we've dealt with the attribute issue to death now.  Shall we
> repeat it again?

I think the only point of agreement is that all mappings must have
compatible attributes, the issue of multiple mappings is still
outstanding, as is needing more fine grained control of the attributes
of a set of compatible mappings (I still need to digest your examples
a little).

> 
> > The DMA API et al. take a CPU centric view of virtual space
> > management, sharing has to be explicitly written and external virtual
> > space management is left up to device driver writers.
> 
> I think I've also shown that not to be the case with example code.
> 
> The code behind the DMA API can be changed on a per-device basis
> (currently on ARM we haven't supported that because no one's asked
> for it yet) so that it can support multiple IOMMUs even of multiple
> different types.

I'm seeing that now. As I become more familiar with the DMA API the
way forward may become more clear to me. I certainly appreciate the
time you've spent discussing things and the code examples you've
listed. For example, it fairly clear how I can use a scatter list to
describe a mapping of big buffers. I can start down this path and see
what shakes out.

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