mm: iommu: An API to unify IOMMU, CPU and device memory management
in [Kernel]
|
Prev: [PATCH] Add a pair of system calls to make extended file stats available [ver #3]
Next: [PATCHv3 3/9] dspbridge: rename bridge_brd_mem_map/unmap to a proper name
From: FUJITA Tomonori on 13 Jul 2010 02:10 On Mon, 12 Jul 2010 22:57:06 -0700 Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote: > FUJITA Tomonori wrote: > > On Thu, 08 Jul 2010 16:59:52 -0700 > > Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote: > > > >> The problem I'm trying to solve boils down to this: map a set of > >> contiguous physical buffers to an aligned IOMMU address. I need to > >> allocate the set of physical buffers in a particular way: use 1 MB > >> contiguous physical memory, then 64 KB, then 4 KB, etc. and I need to > >> align the IOMMU address in a particular way. > > > > Sounds like the DMA API already supports what you want. > > > > You can set segment_boundary_mask in struct device_dma_parameters if > > you want to align the IOMMU address. See IOMMU implementations that > > support dma_get_seg_boundary() properly. > > That function takes the wrong argument in a VCM world: > > unsigned long dma_get_seg_boundary(struct device *dev); > > The boundary should be an attribute of the device side mapping, > independent of the device. This would allow better code reuse. You mean that you want to specify this alignment attribute every time you create an IOMMU mapping? Then you can set segment_boundary_mask every time you create an IOMMU mapping. It's odd but it should work. Another possible solution is extending struct dma_attrs. We could add the alignment attribute to 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/
From: Zach Pfeffer on 13 Jul 2010 08:20 On Tue, Jul 13, 2010 at 03:03:25PM +0900, FUJITA Tomonori wrote: > On Mon, 12 Jul 2010 22:57:06 -0700 > Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote: > > > FUJITA Tomonori wrote: > > > On Thu, 08 Jul 2010 16:59:52 -0700 > > > Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote: > > > > > >> The problem I'm trying to solve boils down to this: map a set of > > >> contiguous physical buffers to an aligned IOMMU address. I need to > > >> allocate the set of physical buffers in a particular way: use 1 MB > > >> contiguous physical memory, then 64 KB, then 4 KB, etc. and I need to > > >> align the IOMMU address in a particular way. > > > > > > Sounds like the DMA API already supports what you want. > > > > > > You can set segment_boundary_mask in struct device_dma_parameters if > > > you want to align the IOMMU address. See IOMMU implementations that > > > support dma_get_seg_boundary() properly. > > > > That function takes the wrong argument in a VCM world: > > > > unsigned long dma_get_seg_boundary(struct device *dev); > > > > The boundary should be an attribute of the device side mapping, > > independent of the device. This would allow better code reuse. > > You mean that you want to specify this alignment attribute every time > you create an IOMMU mapping? Then you can set segment_boundary_mask > every time you create an IOMMU mapping. It's odd but it should work. Kinda. I want to forget about IOMMUs, devices and CPUs. I just want to create a mapping that has the alignment I specify, regardless of the mapper. The mapping is created on a VCM and the VCM is associated with a mapper: a CPU, an IOMMU'd device or a direct mapped device. > > Another possible solution is extending struct dma_attrs. We could add > the alignment attribute to it. That may be useful, but in the current DMA-API may be seen as redundant info. -- 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 22:10 On Tue, 13 Jul 2010 05:14:21 -0700 Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote: > > You mean that you want to specify this alignment attribute every time > > you create an IOMMU mapping? Then you can set segment_boundary_mask > > every time you create an IOMMU mapping. It's odd but it should work. > > Kinda. I want to forget about IOMMUs, devices and CPUs. I just want to > create a mapping that has the alignment I specify, regardless of the > mapper. The mapping is created on a VCM and the VCM is associated with > a mapper: a CPU, an IOMMU'd device or a direct mapped device. Sounds like you can do the above with the combination of the current APIs, create a virtual address and then an I/O address. The above can't be a reason to add a new infrastructure includes more than 3,000 lines. > > Another possible solution is extending struct dma_attrs. We could add > > the alignment attribute to it. > > That may be useful, but in the current DMA-API may be seen as > redundant info. If there is real requirement, we can extend the DMA-API. -- 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 16:20 On Wed, Jul 14, 2010 at 10:59:38AM +0900, FUJITA Tomonori wrote: > On Tue, 13 Jul 2010 05:14:21 -0700 > Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote: > > > > You mean that you want to specify this alignment attribute every time > > > you create an IOMMU mapping? Then you can set segment_boundary_mask > > > every time you create an IOMMU mapping. It's odd but it should work. > > > > Kinda. I want to forget about IOMMUs, devices and CPUs. I just want to > > create a mapping that has the alignment I specify, regardless of the > > mapper. The mapping is created on a VCM and the VCM is associated with > > a mapper: a CPU, an IOMMU'd device or a direct mapped device. > > Sounds like you can do the above with the combination of the current > APIs, create a virtual address and then an I/O address. > Yes, and that's what the implementation does - and all the other implementations that need to do this same thing. Why not solve the problem once? > The above can't be a reason to add a new infrastructure includes more > than 3,000 lines. Right now its 3000 lines because I haven't converted to a function pointer based implementation. Once I do that the size of the implementation will shrink and the code will act as a lib. Users pass buffer mappers and the lib will ease the management of of those buffers. > > > > > Another possible solution is extending struct dma_attrs. We could add > > > the alignment attribute to it. > > > > That may be useful, but in the current DMA-API may be seen as > > redundant info. > > If there is real requirement, we can extend the DMA-API. If the DMA-API contained functions to allocate virtual space separate from physical space and reworked how chained buffers functioned it would probably work - but then things start to look like the VCM API which does graph based map management. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo(a)kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont(a)kvack.org"> email(a)kvack.org </a> -- 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 14 Jul 2010 19:10
On Wed, 14 Jul 2010 13:11:49 -0700 Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote: > On Wed, Jul 14, 2010 at 10:59:38AM +0900, FUJITA Tomonori wrote: > > On Tue, 13 Jul 2010 05:14:21 -0700 > > Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote: > > > > > > You mean that you want to specify this alignment attribute every time > > > > you create an IOMMU mapping? Then you can set segment_boundary_mask > > > > every time you create an IOMMU mapping. It's odd but it should work. > > > > > > Kinda. I want to forget about IOMMUs, devices and CPUs. I just want to > > > create a mapping that has the alignment I specify, regardless of the > > > mapper. The mapping is created on a VCM and the VCM is associated with > > > a mapper: a CPU, an IOMMU'd device or a direct mapped device. > > > > Sounds like you can do the above with the combination of the current > > APIs, create a virtual address and then an I/O address. > > > > Yes, and that's what the implementation does - and all the other > implementations that need to do this same thing. Why not solve the > problem once? Why we we need a new abstraction layer to solve the problem that the current API can handle? The above two operations don't sound too complicated. The combination of the current API sounds much simpler than your new abstraction. Please show how the combination of the current APIs doesn't work. Otherwise, we can't see what's the benefit of your new abstraction. -- 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/ |