On Mon, Jun 02, 2025 at 09:47:18AM -0300, Jason Gunthorpe wrote:
> On Sun, Jun 01, 2025 at 12:25:15AM +0800, Xu Yilun wrote:
> > > + * struct iommu_vdevice_id - ioctl(IOMMU_VDEVICE_TSM_BIND/UNBIND)
> > > + * @size: sizeof(struct iommu_vdevice_id)
> > > + * @vdevice_id: Object handle for the vDevice. Returned from IOMMU_VDEVICE_ALLOC
> > > + */
> > > +struct iommu_vdevice_id {
> > > + __u32 size;
> > > + __u32 vdevice_id;
> > > +} __packed;
> > > +#define IOMMU_VDEVICE_TSM_BIND _IO(IOMMUFD_TYPE, IOMMUFD_CMD_VDEVICE_TSM_BIND)
> > > +#define IOMMU_VDEVICE_TSM_UNBIND _IO(IOMMUFD_TYPE, IOMMUFD_CMD_VDEVICE_TSM_UNBIND)
> >
> > Hello, I see you are talking about the detailed implementation. But
> > could we firstly address the confusing whether this TSM Bind/Unbind
> > should be a VFIO uAPI or IOMMUFD uAPI?
>
> I thought you guys had moved past that?
Not yet.
> VFIO doesn't have enough
> information so iommufd would be a better place to make the call?
VFIO doesn't have enough information, but VFIO needs to know about
bound state. So comes the suggestion [1] that the VFIO uAPI, then VFIO
reach into iommufd for real bind.
And my implementation [2] is:
ioctl(vfio_cdev_fd, VFIO_DEVICE_TSM_BIND)
-> vfio_iommufd_tsm_bind()
-> iommufd_device_tsm_bind()
-> iommufd_vdevice_tsm_bind()
-> pci_tsm_bind()
[2]: https://lore.kernel.org/all/20250529053513.1592088-1-yilun.xu@xxxxxxxxxxxxxxx/
> In this thread [1], I was talking about TSM Bind/Unbind affects VFIO
> behavior so they cannot be iommufd uAPIs which VFIO is not aware of.
> At least TDX Connect cares about this problem now. And the conclusion
> seems to be "have a VFIO_DEVICE_BIND(iommufd vdevice id), then have
> VFIO reach into iommufd".
>
> And some further findings [2] indicate this problem may also exist on
> AMD when p2p is involved.
>
> [1]: https://lore.kernel.org/all/20250515175658.GR382960@xxxxxxxxxx/
>
> Jason
