mm: iommu: The Virtual Contiguous Memory Manager
in [Kernel]
|
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: Zach Pfeffer on 13 Jul 2010 08:10 On Tue, Jul 13, 2010 at 02:59:08PM +0900, FUJITA Tomonori wrote: > 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). I'm not sure, but I know that it makes the distinction. From video4linux/videobuf: <media/videobuf-dma-sg.h> /* Physically scattered */ <media/videobuf-vmalloc.h> /* vmalloc() buffers */ <media/videobuf-dma-contig.h> /* Physically contiguous */ -- 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 22:10 On Tue, 13 Jul 2010 10:02:23 +0100 Russell King - ARM Linux <linux(a)arm.linux.org.uk> wrote: > On Tue, Jul 13, 2010 at 05:45:39PM +0900, FUJITA Tomonori wrote: > > Drivers can tell the USB layer that these are vmapped buffers? Adding > > something to struct urb? I might be totally wrong since I don't know > > anything about the USB layer. > > With non-DMA coherent aliasing caches, you need to know where the page > is mapped into the virtual address space, so you can deal with aliases. > > You'd need to tell the USB layer about the other mappings of the page > which you'd like to be coherent (such as the vmalloc area - and there's > also the possible userspace mapping to think about too, but that's > a separate issue.) > > I wonder if we should have had: > > vmalloc_prepare_dma(void *, size_t, enum dma_direction) > vmalloc_finish_dma(void *, size_t, enum dma_direction) > > rather than flush_kernel_vmap_range and invalidate_kernel_vmap_range, > which'd make their use entirely obvious. > > However, this brings up a question - how does the driver (eg, v4l, xfs) > which is preparing the buffer for another driver (eg, usb host, block > dev) know that DMA will be performed on the buffer rather than PIO? > > That's a very relevant question, because for speculatively prefetching > CPUs, we need to invalidate caches after a DMA-from-device operation - > but if PIO-from-device happened, this would destroy data read from the > device. > > That problem goes away if we decide that PIO drivers must have the same > apparant semantics as DMA drivers - in that data must end up beyond the > point of DMA coherency (eg, physical page) - but that's been proven to > be very hard to achieve, especially with block device drivers. Yeah, the last thing we want to do is converting all the PIO drivers. Seems that we are far from the original discussion (the most of the above topics have been discussed in the past and we kinda agree that we have to do something some time, I guess). 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. 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. -- 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: Joerg Roedel on 14 Jul 2010 15:40 On Mon, Jul 12, 2010 at 10:21:05PM -0700, Zach Pfeffer wrote: > Joerg Roedel wrote: > > The DMA-API already does this with the help of IOMMUs if they are > > present. What is the benefit of your approach over that? > > The grist to the DMA-API mill is the opaque scatterlist. Each > scatterlist element brings together a physical address and a bus > address that may be different. The set of scatterlist elements > constitute both the set of physical buffers and the mappings to those > buffers. My approach separates these two things into a struct physmem > which contains the set of physical buffers and a struct reservation > which contains the set of bus addresses (or device addresses). Each > element in the struct physmem may be of various lengths (without > resorting to chaining). A map call maps the one set to the other. Okay, thats a different concept, where is the benefit? 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 14 Jul 2010 21:20 On Wed, Jul 14, 2010 at 09:34:03PM +0200, Joerg Roedel wrote: > On Mon, Jul 12, 2010 at 10:21:05PM -0700, Zach Pfeffer wrote: > > Joerg Roedel wrote: > > > > The DMA-API already does this with the help of IOMMUs if they are > > > present. What is the benefit of your approach over that? > > > > The grist to the DMA-API mill is the opaque scatterlist. Each > > scatterlist element brings together a physical address and a bus > > address that may be different. The set of scatterlist elements > > constitute both the set of physical buffers and the mappings to those > > buffers. My approach separates these two things into a struct physmem > > which contains the set of physical buffers and a struct reservation > > which contains the set of bus addresses (or device addresses). Each > > element in the struct physmem may be of various lengths (without > > resorting to chaining). A map call maps the one set to the other. > > Okay, thats a different concept, where is the benefit? The benefit is that virtual address space and physical address space are managed independently. This may be useful if you want to reuse the same set of physical buffers, a user simply maps them when they're needed. It also means that different physical memories could be targeted and a virtual allocation could map those memories without worrying about where they were. This whole concept is just a logical extension of the already existing separation between pages and page frames... in fact the separation between physical memory and what is mapped to that memory is fundamental to the Linux kernel. This approach just says that arbitrary long buffers should work the same way. -- 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 22 Jul 2010 00:00
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. -- 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/ |