To extend the feature of vfio-mdev

[Jean-Philippe Brucker]

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