On 3/6/25 03:17, Xu Yilun wrote:
On Mon, Jun 02, 2025 at 02:52:52PM +1000, Alexey Kardashevskiy wrote:
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?
And do unbind before zapping MMIO.
Or, more to the point, what is that exact thing which cannot be done from QEMU? Thanks,
But kernel don't want incorrect userspace calls crash kernel, e.g. VFIO
zaps MMIO on TDI bound then KVM just crashes. So you need to check if
zapping MMIOs are allowed in VFIO, that means VFIO still needs to know
if device is bound. Scatter BIND/UNBIND & other device controls in both
IOMMUFD & VFIO makes life harder.
I am confused. What is that userspace call, ioctl(VFIO_DEVICE_RESET)? The userspace (==QEMU) knows it is bound and can unbind first, no?
If it is the case of killing QEMU - then there is no usespace and then it is a matter of what fd is closed first - VFIO-PCI or IOMMUFD, we could teach IOMMUFD to hold an VFIO-PCI fd to guarantee the order. Thanks,
Thanks,
Yilun
--
Alexey
