Hi Kenneth, On 17/11/17 09:29, Kenneth Lee wrote: [...] > Hi, Jean, > > I read your patchset on git://linux-arm.org/linux-jpb in branch > svm/rfc2. > > I don't understand why you bind the multiple asid/pasid feature with > SVM. I think it is risky. With PASID we're dedicating a device thread to a process. Why is it more risky than dedicating a CPU thread to a process? The main goal of SVM is to reduce the amount of shoddy memory management in device drivers and userspace, and reuse what mm/ offers instead. So bind/unbind will most likely be less risky than what we have now. The risk is if the device is buggy and doesn't isolate its PASID threads properly, in which case managing PASIDs with map/unmap won't help, you're basically back to one thread per device. > The performance of SVM is still a risk to many hardware. Do you mean that enabling swapping with PRI/stall will perform worse than pining everything with IOMMU map/unmap? Probable, but it's too early to tell. Playing with mlock/munlock syscalls might also help a little. In any case, SVM is more about productivity than performance. > It rely on the workflow. In many cases, we just need to > create a page table particularly for the devices itself without > dedicate the whole process space to it. Yes, that seems to be a popular use-case. For the next version I'm working on providing a map/unmap feature per PASID: http://www.spinics.net/lists/arm-kernel/msg613586.html I'm enabling it in the low-level SMMU code, but I'm not sure if the API will be in my next version or in a future series, my hands are full at the moment. The bind/unbind API is easier to design because is inspires from the intel and amd bind/unbind features, that already have users. Thanks, Jean
