On Wed, Nov 04, 2015 at 02:12:03PM +0900, Tomasz Figa wrote: > My understanding of a scatterlist was that it represents a buffer as a > whole, by joining together its physically discontinuous segments. Correct, and it may also be scattered in CPU virtual space as well. > I don't see how single segments (layout of which is completely up to > the allocator; often just single pages) would be usable for hardware > that needs to do some work more serious than just writing a byte > stream continuously to subsequent buffers. In case of such simple > devices you don't even need an IOMMU (for means other than protection > and/or getting over address space limitations). All that's required is that the addresses described in the scatterlist are accessed as an apparently contiguous series of bytes. They don't have to be contiguous in any address view, provided the device access appears to be contiguous. How that is done is really neither here nor there. IOMMUs are normally there as an address translator - for example, the underlying device may not have the capability to address a scatterlist (eg, because it makes effectively random access) and in order to be accessible to the device, it needs to be made contiguous in device address space. Another scenario is that you have more bits of physical address than a device can generate itself for DMA purposes, and you need an IOMMU to create a (possibly scattered) mapping in device address space within the ability of the device to address. The requirements here depend on the device behind the IOMMU. > However, IMHO the most important use case of an IOMMU is to make > buffers, which are contiguous in CPU virtual address space (VA), > contiguous in device's address space (IOVA). No - there is no requirement for CPU virtual contiguous buffers to also be contiguous in the device address space. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
