Hi Jean, On 2017/10/12 20:55, Jean-Philippe Brucker wrote: > On 12/10/17 13:05, Yisheng Xie wrote: > [...] >>>>> * An iommu_process can be bound to multiple domains, and a domain can have >>>>> multiple iommu_process. >>>> when bind a task to device, can we create a single domain for it? I am thinking >>>> about process management without shared PT(for some device only support PASID >>>> without pri ability), it seems hard to expand if a domain have multiple iommu_process? >>>> Do you have any idea about this? >>> >>> A device always has to be in a domain, as far as I know. Not supporting >>> PRI forces you to pin down all user mappings (or just the ones you use for >>> DMA) but you should sill be able to share PT. Now if you don't support >>> shared PT either, but only PASID, then you'll have to use io-pgtable and a >>> new map/unmap API on an iommu_process. I don't understand your concern >>> though, how would the link between process and domains prevent this use-case? >>> >> So you mean that if an iommu_process bind to multiple devices it should create >> multiple io-pgtables? or just share the same io-pgtable? > > I don't know to be honest, I haven't thought much about the io-pgtable > case, I'm all about sharing the mm :) > Sorry to get back to this thread, but traditional DMA_MAP use case may also want to enable Substreamid/PASID. As a general framework, you may also consider SubStreamid/Pasid support for dma map/io-pgtable. We're considering make io-pgtables per SubStreamid/Pasid, but haven't decide put all io-pgtables into a single domain or iommu_process. Thanks, Liubo > It really depends on what the user (GPU driver I assume) wants. I think > that if you're not sharing an mm with the device, then you're trying to > hide parts of the process to the device, so you'd also want the > flexibility of having different io-pgtables between devices. Different > devices accessing isolated parts of the process requires separate io-pgtables. > -- 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
