Re: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

[Jason Wang <jasowang@redhat.com>]

On 2020/9/14 下午9:31, Jean-Philippe Brucker wrote:
>> If it's possible, I would suggest a generic uAPI instead of a VFIO specific
>> one.
> A large part of this work is already generic uAPI, in
> include/uapi/linux/iommu.h.


This is not what I read from this series, all the following uAPI is VFIO 
specific:

struct vfio_iommu_type1_nesting_op;
struct vfio_iommu_type1_pasid_request;

And include/uapi/linux/iommu.h is not included in 
include/uapi/linux/vfio.h at all.



> This patchset connects that generic interface
> to the pre-existing VFIO uAPI that deals with IOMMU mappings of an
> assigned device. But the bulk of the work is done by the IOMMU subsystem,
> and is available to all device drivers.


So any reason not introducing the uAPI to IOMMU drivers directly?


>
>> Jason suggest something like /dev/sva. There will be a lot of other
>> subsystems that could benefit from this (e.g vDPA).
> Do you have a more precise idea of the interface /dev/sva would provide,
> how it would interact with VFIO and others?


Can we replace the container fd with sva fd like:

sva = open("/dev/sva", O_RDWR);
group = open("/dev/vfio/26", O_RDWR);
ioctl(group, VFIO_GROUP_SET_SVA, &sva);

Then we can do all SVA stuffs through sva fd, and for other subsystems 
(like vDPA) it only need to implement the function that is equivalent to 
VFIO_GROUP_SET_SVA.


>    vDPA could transport the
> generic iommu.h structures via its own uAPI, and call the IOMMU API
> directly without going through an intermediate /dev/sva handle.


Any value for those transporting? I think we have agreed that VFIO is 
not the only user for vSVA ...

It's not hard to forecast that there would be more subsystems that want 
to benefit from vSVA, we don't want to duplicate the similar uAPIs in 
all of those subsystems.

Thanks


>
> Thanks,
> Jean
>