Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx> writes:
>> + * 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?
>
> 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/
> [2]: https://lore.kernel.org/all/aDnXxk46kwrOcl0i@yilunxu-OptiPlex-7050/
>
Looking at your patch series, I understand the reason you need a vfio
ioctl is to call pci_request_regions_exclusive—is that correct?
In another thread, I asked whether this might be better handled by
pci_tsm instead of vfio. I'd be interested in your thoughts on that.
I also noticed you want to unbind the TDI before unmapping the BAR in
vfio. From what I understand, this should still be possible if we use an
iommufd ioctl. Either approach—a vfio or iommufd ioctl—works fine for my
needs. We can continue that discussion in your patch series thread.
-aneesh
