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
