Prev: [PATCH v2]kernel.h Move preprocessor #warning about using kernel headers in userpsace to types.h
Next: scsi/sg: remove casts from void*
From: Joerg Roedel on 10 Jul 2010 11:20 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 13 Jul 2010 01:30 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 13 Jul 2010 01:50 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 13 Jul 2010 02:00 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 13 Jul 2010 02:10
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/ |