To extend the feature of vfio-mdev
Kenneth-Lee-2012 at foxmail.com
Sat Nov 18 14:35:43 AEDT 2017
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
> 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
> > 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:
> 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.
-Kenneth Lee (Hisilicon)
More information about the Linux-accelerators