To extend the feature of vfio-mdev

Kenneth Lee Kenneth-Lee-2012 at
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>
> To: Kenneth Lee <Kenneth-Lee-2012 at>
> Cc: Alex Williamson <alex.williamson at>, "xuzaibo at"
>  <xuzaibo at>, "linux-accelerators at"
>  <linux-accelerators at>, "liguozhu at"
>  <liguozhu at>
> Subject: Re: To extend the feature of vfio-mdev
> Message-ID: <df2c0698-ecbf-bc80-503a-b08d376e8491 at>
> Hi Kenneth,
> On 17/11/17 09:29, Kenneth Lee wrote:
> [...]
> > Hi, Jean,
> > 
> > I read your patchset on git:// 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
> > 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.

> Thanks,
> Jean

			-Kenneth Lee (Hisilicon)

More information about the Linux-accelerators mailing list