PCI: Add DMA alias quirk for Microsemi Switchtec NTB
Add a quirk for the Microsemi Switchtec parts to allow DMA access via non-transparent bridging to work when the IOMMU is turned on. This exclusively addresses the ability of a remote NT endpoint to perform DMA accesses through the locally enumerated NT endpoint. Other aspects of the Switchtec NTB functionality, such as interrupts for doorbells and messages are independent of this quirk, and will work whether the IOMMU is on or off. When a requestor on one NT endpoint accesses memory on another NT endpoint, it does this via a devfn proxy ID. Proxy IDs are statically assigned to each NT endpoint by the NTB hardware as part of the release-from-reset sequence prior to PCI enumeration. These proxy IDs cannot be modified dynamically, and are not visible to the host during enumeration. When the Switchtec NTB driver loads it will map local requestor IDs, such as the root complex and transparent bridge DMA engines, to proxy IDs by populating those requestor IDs in hardware mapping table table entries. This establishes a fixed relationship between a requestor ID and a proxy ID. When a peer on a remote NT endpoint performs an access within a particular translation window in it's NT endpoint BAR address space, that access is translated to a DMA request on the local endpoint's bus. As part of the translation process, the original requestor ID has its devfn replaced with the proxy ID, and the bus portion of the BDF is replaced with the bus of the local NT endpoint. Thus, the DMA access from a remote NT endpoint will appear on the local bus to have come from the unknown devfn which the IOMMU will reject. Interrogate NTB hardware registers for each remote NT endpoint to obtain the proxy IDs that have been assigned to it and alias them to the local (enumerated) NT endpoint's device. The IOMMU then accepts the remote proxy IDs as if they were requests coming directly from the enumerated endpoint, giving remote requestors access to memory resources which the local host has made available. Note that the aliasing of the proxy IDs cannot be performed at the driver level given the current IOMMU architecture. Superficially this is because pci_add_dma_alias() symbol is not exported. Functionally, the current IOMMU design requires the aliasing to be performed prior to the creation of IOMMU groups. If a driver were to attempt to use pci_add_dma_alias() in its probe routine it would fail since the IOMMU groups have been set up by that time. If the Switchtec hardware supported dynamic proxy ID (re-)assignment this would be an issue, but it does not. To further clarify static proxy ID assignment: While the requester ID to proxy ID mapping can be dynamically changed, the number and value of proxy IDs given to an NT EP cannot, even for dynamic reconfiguration such as hot-add. Therefore, the chip configuration must account a priori for the proxy IDs needs, considering both static and dynamic system configurations. For example, a port on the chip may not having anything plugged into it at start of day; but it must have a sufficient number of proxy IDs assigned to accommodate the supported devices which may be hot-added. Switchtec NTB functionality with the IOMMU off is unchanged by this quirk. Signed-off-by: NDoug Meyer <dmeyer@gigaio.com> [bhelgaas: use hard-coded Device IDs instead of adding #defines for each] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NLogan Gunthorpe <logang@deltatee.com>
Showing
想要评论请 注册 或 登录