Subject: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

From: [email-masked] (Zach Pfeffer)
Date: Wed, 21 Jul 2010 20:50:26 -0700

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 can't find any reasonable reasons that we need to merge VCM; seems
> that the combination of the current APIs (or with some small
> extensions) can work for the issues that VCM tries to solve.

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. At this point if you need to
work with big buffers, 1 MB and 16 MB etc, and map those big buffers
to non-CPU virtual spaces you need to explicitly carve them out and
set up the mappings and sharing by hand. Its reasonable to have an API
that can do this especially since IOMMUs are going to become more
prevalent. 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. Given a system
where each device has an IOMMU or a MMU the whole concept of a
scatterlist goes away. The VCM API gets a jump on it.