Hi Liubo, On 08/11/17 01:21, Bob Liu wrote: > 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. Yes they should be in a single domain, see also my other reply here: http://www.spinics.net/lists/arm-kernel/msg613586.html I've only been thinking about the IOMMU API for the moment, but I guess the VFIO API would use this extension? I suppose it would be a new PASID field to DMA_MAP along with a flag. The PASID would probably be allocated with BIND + some special flag. Thanks, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
