On 1/6/25 02:25, 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?
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.
What will the host VFIO-PCI driver do differently? I only remember "stop mmaping to the userspace", is that all? Or, more to the point, what is that exact thing which cannot be done from QEMU? Thanks,
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/
Thanks,
Yilun
+
+
/**
* struct iommufd_vevent_header - Virtual Event Header for a vEVENTQ Status
* @flags: Combination of enum iommu_veventq_flag
--
2.43.0
--
Alexey
