On Fri, Nov 17, 2017 at 11:13:22AM +0000, Jean-Philippe Brucker wrote: > Date: Fri, 17 Nov 2017 11:13:22 +0000 > From: Jean-Philippe Brucker <jean-philippe.brucker@xxxxxxx> > To: Kenneth Lee <Kenneth-Lee-2012@xxxxxxxxxxx> > Cc: Alex Williamson <alex.williamson@xxxxxxxxxx>, "xuzaibo@xxxxxxxxxx" > <xuzaibo@xxxxxxxxxx>, "linux-accelerators@xxxxxxxxxxxxxxxx" > <linux-accelerators@xxxxxxxxxxxxxxxx>, "liguozhu@xxxxxxxxxxxxx" > <liguozhu@xxxxxxxxxxxxx> > Subject: Re: To extend the feature of vfio-mdev > Message-ID: <df2c0698-ecbf-bc80-503a-b08d376e8491@xxxxxxx> > > 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. When I said it was risky, I means some devices may not implement SVM feature (such as ATS/PRI). But they still need to provide service to more than one process. But as you said below, you will add map/unmap feature per PASID (I think you refer to iommu_process), it would not be a problem. > > 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. Yes, pre-fault is a solution of SVM. I was just worrying the non-SVM cases. > > > 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. Thank you. I will try to test this in our scenarios. > > Thanks, > Jean -- -Kenneth Lee (Hisilicon)
