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.
Thanks,
Yilun
