To extend the feature of vfio-mdev

[Kenneth Lee]

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 at arm.com>
> To: Kenneth Lee <Kenneth-Lee-2012 at foxmail.com>
> Cc: Alex Williamson <alex.williamson at redhat.com>, "xuzaibo at huawei.com"
>  <xuzaibo at huawei.com>, "linux-accelerators at lists.ozlabs.org"
>  <linux-accelerators at lists.ozlabs.org>, "liguozhu at hisilicon.com"
>  <liguozhu at hisilicon.com>
> Subject: Re: To extend the feature of vfio-mdev
> Message-ID: <df2c0698-ecbf-bc80-503a-b08d376e8491 at arm.com>
> 
> 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)