On Mon, Jun 02, 2025 at 04:38:09PM +0530, Aneesh Kumar K.V wrote:
> 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?
The immediate reason is to unbind the TDI before unmapping the BAR.
>
> 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.
I'm not sure how is that possible.
> Either approach—a vfio or iommufd ioctl—works fine for my
> needs. We can continue that discussion in your patch series thread.
Yeah, let's discuss in that thread.
>
> -aneesh
