On Wed, May 28, 2025 at 01:52:22PM -0300, Jason Gunthorpe wrote:
> 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]
Then we should have more verbose TSM APIs,
pci_tsm_tdi_create/bind/unbind/free(), which seems workable. Now
according to Dan's series, we only have bind() which creates secure
vPCI and switch to T=1, and unbind() which switch to T=0 and free secure
vPCI.
Thanks,
Yilun
>
> 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
