On Tue, 29 Apr 2014 23:00:29 +0200, Arnd Bergmann wrote: > On Tuesday 29 April 2014 13:07:54 Grant Grundler wrote: > > On Tue, Apr 29, 2014 at 11:16 AM, Dave Martin <[email protected]> wrote: > > ... > > > An IOMMU is really a specialised bridge > > > > Is a GART a bridge? > > > > IOMMUs can provide three basic functions: > > 1) remap address space to reach phys mem ranges that the device is > > otherwise not capable of accessing (classic 32-bit DMA to reach 64-bit > > Phys address) > > > > 2) implement scatter-gather (page level granularity) so the device > > doesn't have to > > > > 3) provide some level of system protection against "rogue" DMA by > > forcing everything through a DMA mapping interface and faulting when > > encountering unmapped DMA transactions. > > [ 4) provide isolation between multiple contexts, typically for purposes > of virtualization] > > > I summarize IOMMUs as: "participate in the routing of MMIO > > transactions in the system fabric." > > In this sense, IOMMUs are sort of a bridge. Defining what kind of > > routing they can do (coalesce transactions? remapping MMIO domains?) > > and which address ranges they route would describe most of that > > functionality. > > > > This "remapping" of MMIO transaction is also usually asymmetric. > > Meaning routing of "downstream" transactions *might* be completely > > different than the routing + remapping of transactions heading > > upstream. DMA mappings services are designed to handle only the > > transactions generated (aka "mastered") by a downstream device. > > For the purposes of the DT binding, we have a 'ranges' property > that defines the downstream translation (CPU-to-MMIO) and a > 'dma-ranges' property for the opposite address translation > (device-to-memory). > > > >, so it may be cleaner to describe > > > an IOMMU using a real bus node in the DT, if we also define a way to make > > > master/slave linkages explicit where it matters. > > > > "where it matters" is a bit vague. Is the goal to just enable DMA > > mapping services to "do the right thing" for a device that can > > generate DMA? > > Yes. It's very complicated unfortunately, because we have to be > able to deal with arbitrary combinations of a lot of oddball cases > that can show up in random SoCs: > > - device can only do DMA to a limited address range > - DMA is noncoherent and needs manual cache management > - DMA address is at an offset from physical address > - some devices have an IOMMU > - some IOMMUs are shared between devices > - some devices with IOMMU can have multiple simultaneous contexts > - a device may access some memory directly and some other memory through IOMMU
Do we need to consider this case? I don't think a device can have different contexts at the same time. If there such device is in a system, its driver must handle it correctly with different devices descriptors for the different contexts, for example. I mean, if a device has two DMA ports that are in different contexts, they can be treated as different devices which are handed by a driver. I worry that abstracting everything we can think may make the problem harder. Regards, KyongHo > - a device may have DMA access to a bus that is invisible to the CPU > - DMA on some device is only coherent if the IOMMU is enabled > - DMA on some device is only coherent if the IOMMU is disabled > - the IOVA range to an IOMMU is device dependent > > > > I've been hacking around some proposals on these areas which are a bit > > > different from the approach suggested here -- I'll try to summarise some > > > of it intelligibly and post something tomorrow so that we can discuss. > > > > Are you planning on consolidating Documentation/devicetree/bindings/iommu/ ? > > Do you care about Documentation/Intel-IOMMU.txt? > > I think we can ignore the Intel-IOMMU because that is specialized on PCI > devices, which we don't normally represent in DT. It is also a special > case because the Intel IOMMU is a single-instance device. If it's present > and enabled, it will be used by every device. The case we do need to describe > is when we don't know which IOMMU is used for which master, or how to > configure it. > > Arnd _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
