[lkml]   [2010]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Daniel Walker wrote:
> On Thu, 2010-07-01 at 15:00 -0700, Zach Pfeffer wrote:
>> Additionally, the current IOMMU interface does not allow users to
>> associate one page table with multiple IOMMUs unless the user explicitly
>> wrote a muxed device underneith the IOMMU interface. This also could be
>> done, but would have to be done for every such use case. Since the
>> particular topology is run-time configurable all of these use-cases and
>> more can be expressed without pushing the topology into the low-level
>> IOMMU driver.
>> The VCMM takes the long view. Its designed for a future in which the
>> number of IOMMUs will go up and the ways in which these IOMMUs are
>> composed will vary from system to system, and may vary at
>> runtime. Already, there are ~20 different IOMMU map implementations in
>> the kernel. Had the Linux kernel had the VCMM, many of those
>> implementations could have leveraged the mapping and topology management
>> of a VCMM, while focusing on a few key hardware specific functions (map
>> this physical address, program the page table base register).
> So if we include this code which "map implementations" could you
> collapse into this implementations ? Generally , what currently existing
> code can VCMM help to eliminate?

In theory, it can eliminate all code the interoperates between IOMMU,
CPU and non-IOMMU based devices and all the mapping code, alignment,
mapping attribute and special block size support that's been

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

 \ /
  Last update: 2010-07-02 09:37    [W:0.117 / U:1.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site