On 01/03/18 08:04, Christian König wrote: > Am 01.03.2018 um 07:52 schrieb Lu Baolu: >> Hi Jean, >> >> On 02/13/2018 02:33 AM, Jean-Philippe Brucker wrote: >>> [SNIP] >>> + pasid = idr_alloc_cyclic(&iommu_pasid_idr, io_mm, dev_param->min_pasid, >>> + dev_param->max_pasid + 1, GFP_ATOMIC); >> Can the pasid management code be moved into a common library? >> PASID is not stick to SVA. An IOMMU model device could be designed >> to use PASID for second level translation (classical DMA translation) >> as well. > > Yeah, we have the same problem on amdgpu. > > We assign PASIDs to clients even when IOMMU isn't present in the system > just because we need it for debugging. > > E.g. when the hardware detects that some shader program is doing > something nasty we get the PASID in the interrupt and could for example > use it to inform the client about the fault. This seems like a new requirement altogether, and a bit outside the scope of this series to be honest. Is the client userspace in this context? I guess it would be mostly for prototyping then? Otherwise you probably don't want to hand GPU contexts to userspace without an IOMMU isolating them? If you don't need mm tracking/sharing or iommu_map/unmap, then maybe an IDR private to the GPU driver would be enough? If you do need mm tracking, I suppose we could modify iommu_sva_bind() to allocate and track io_mm even if the given device doesn't have an IOMMU, but it seems a bit backward. Thanks, Jean -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
