On Wed, May 28, 2025 at 01:42:25PM -0300, Jason Gunthorpe wrote:
> > +int iommufd_vdevice_tsm_bind_ioctl(struct iommufd_ucmd *ucmd)
> > +{
> > + struct iommu_vdevice_id *cmd = ucmd->cmd;
> > + struct iommufd_vdevice *vdev;
> > + int rc = 0;
> > +
> > + vdev = container_of(iommufd_get_object(ucmd->ictx, cmd->vdevice_id,
> > + IOMMUFD_OBJ_VDEVICE),
> > + struct iommufd_vdevice, obj);
> > + if (IS_ERR(vdev))
> > + return PTR_ERR(vdev);
> > +
> > + rc = tsm_bind(vdev->dev, vdev->viommu->kvm, vdev->id);
>
> Yeah, that makes alot of sense now, you are passing in the KVM for the
> VIOMMU and both the vBDF and pBDF to the TSM layer, that should be
> enough for it to figure out what to do. The only other data would be
> the TSM's VIOMMU handle..
Actually it should also check that the viommu type is compatible with
the TSM, somehow.
The way I imagine this working is userspace would create a
IOMMU_VIOMMU_TYPE_TSM_VTD (for example) viommu object which will do a
TSM call to setup the secure vIOMMU
Then when you create a VDEVICE against the IOMMU_VIOMMU_TYPE_TSM_VTD
it will do a TSM call to create the secure vPCI function attached to
the vIOMMU and register the vBDF. [1]
And finally bind will switch to T=1 mode.
But if someone creates a VIOMMU with IOMMU_VIOMMU_TYPE_ARM_SMMUV3 then
the vdevice shouldn't be allowed to work in TSM mode at all.
Finally IOMMU_VIOMMU_TYPE_TSM_NO_VIOMMU would be a "NOP" viommu type
that enables TSM support but has no vIOMMU and works with all the
iommu drivers.
Not sure exactly how to wrangle this all, but it should be done
here..
1 - IMHO alot of the architectures I've seen have messed up the VIOMMU
design by having completely separate IOMMUs for T=1 and T=0 traffic. I
hope people will fix this and allow the secure VIOMMU to translate
both T=0 and T=1 traffic as walking page tables in secure memory and
then rejecting T=0 if the final physical is secure memory. Meaning
from an API perspective we want the vPCI to possibly have a working
secure vIOMMU before we reach bind.
Jason
