From: Joerg Roedel on
On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote:
> Andi Kleen wrote:

> > Hmm? dma_map_* does not change any CPU mappings. It only sets up
> > DMA mapping(s).
>
> Sure, but I was saying that iommu_map() doesn't just set up the IOMMU
> mappings, its sets up both the iommu and kernel buffer mappings.

What do you mean by kernel buffer mappings?


> > That assumes that all the IOMMUs on the system support the same page table
> > format, right?
>
> Actually no. Since the VCMM abstracts a page-table as a Virtual
> Contiguous Region (VCM) a VCM can be associated with any device,
> regardless of their individual page table format.

The IOMMU-API abstracts a page-table as a domain which can also be
associated with any device (behind an iommu).

Joerg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Zach Pfeffer on
Joerg Roedel wrote:
> On Thu, Jul 01, 2010 at 03:00:17PM -0700, Zach Pfeffer wrote:
>> Additionally, the current IOMMU interface does not allow users to
>> associate one page table with multiple IOMMUs [...]
>
> Thats not true. Multiple IOMMUs are completly handled by the IOMMU
> drivers. In the case of the IOMMU-API backend drivers this also includes
> the ability to use page-tables on multiple IOMMUs.

Yeah. I see that now.

>
>> 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 IOMMU driver has to know about the topology anyway because it needs
> to know which IOMMU it needs to program for a particular device.

Perhaps, but why not create a VCM which can be shared across all
mappers in the system? Why bury it in a device driver and make all
IOMMU device drivers managed their own virtual spaces? Practically
this would entail a minor refactor to the fledging IOMMU interface;
adding associate and activate ops.

>
>> 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).
>
> I partially agree here. All the IOMMU implementations in the Linux
> kernel have a lot of functionality in common where code could be
> shared. Work to share code has been done in the past by Fujita Tomonori
> but there are more places to work on. I am just not sure if a new
> front-end API is the right way to do this.

I don't really think its a new front end API. Its just an API that
allows easier mapping manipulation than the current APIs.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Zach Pfeffer on
Joerg Roedel wrote:
> On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote:
>> Daniel Walker wrote:
>
>>> 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
>> implemented.
>
> Thats a very abstract statement. Can you point to particular code files
> and give a rough sketch how it could be improved using VCMM?

I can. Not to single out a particular subsystem, but the video4linux
code contains interoperation code to abstract the difference between
sg buffers, vmalloc buffers and physically contiguous buffers. The
VCMM is an attempt to provide a framework where these and all the
other buffer types can be unified.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Zach Pfeffer on
Joerg Roedel wrote:
> On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote:
>> Andi Kleen wrote:
>
>>> Hmm? dma_map_* does not change any CPU mappings. It only sets up
>>> DMA mapping(s).
>> Sure, but I was saying that iommu_map() doesn't just set up the IOMMU
>> mappings, its sets up both the iommu and kernel buffer mappings.
>
> What do you mean by kernel buffer mappings?

In-kernel mappings whose addresses can be dereferenced.

>
>
>>> That assumes that all the IOMMUs on the system support the same page table
>>> format, right?
>> Actually no. Since the VCMM abstracts a page-table as a Virtual
>> Contiguous Region (VCM) a VCM can be associated with any device,
>> regardless of their individual page table format.
>
> The IOMMU-API abstracts a page-table as a domain which can also be
> associated with any device (behind an iommu).

It does, but only by convention. The domain member is just a big
catchall void *. It would be more useful to factor out a VCM
abstraction, with associated ops. As it stands all IOMMU device driver
writters have to re-invent IOMMU virtual address management.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on
On Mon, 12 Jul 2010 22:46:59 -0700
Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote:

> Joerg Roedel wrote:
> > On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote:
> >> Daniel Walker wrote:
> >
> >>> 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
> >> implemented.
> >
> > Thats a very abstract statement. Can you point to particular code files
> > and give a rough sketch how it could be improved using VCMM?
>
> I can. Not to single out a particular subsystem, but the video4linux
> code contains interoperation code to abstract the difference between
> sg buffers, vmalloc buffers and physically contiguous buffers. The
> VCMM is an attempt to provide a framework where these and all the
> other buffer types can be unified.

Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed
buffers is a thing that we should avoid (there are some exceptions
like xfs though).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/