On Thu, May 15, 2025 at 02:56:58PM -0300, Jason Gunthorpe wrote: > On Fri, May 16, 2025 at 12:04:04AM +0800, Xu Yilun wrote: > > > arches this was mostly invisible to the hypervisor? > > > > Attest & Accept can be invisible to hypervisor, or host just help pass > > data blobs between guest, firmware & device. > > > > Bind cannot be host agnostic, host should be aware not to touch device > > after Bind. > > I'm not sure this is fully true, this could be a Intel thing. When the > vPCI is created the host can already know it shouldn't touch the PCI > device anymore and the secure world would enforce that when it gets a > bind command. > > The fact it hasn't been locked out immediately at vPCI creation time > is sort of a detail that doesn't matter, IMHO.
I see, SW can define the lock out in a wider range. I suddenly understand you are considering finish all host side CC setup on viommu_alloc & vdevice_alloc before KVM run, then "Bind" could host agnostic, and TDISP LOCK/STOP could also be a guest_request. Now the problem is for TDX, host cannot be agnostic to LOCK/STOP because of the KVM MMIO mapping ... I still have to make VFIO uAPIs for "Bind"/"Unbind" > > > > It might be reasonable to have VFIO reach into iommufd to do that on > > > an already existing iommufd VDEVICE object. A little weird, but we > > > could probably make that work. > > > > Mm, Are you proposing an uAPI in VFIO, and a kAPI from VFIO -> IOMMUFD like: > > > > ioctl(vfio_fd, VFIO_DEVICE_ATTACH_VDEV, vdev_id) > > -> iommufd_device_attach_vdev() > > -> tsm_tdi_bind() > > Not ATTACH, you wanted BIND. You could have a VFIO_DEVICE_BIND(iommufd > vdevice id) Yes. > > > > sees VFIO remove the S-EPT and release the KVM, then have iommufd > > > destroy the VDEVICE object. > > > > Regarding VM destroy, TDX Connect has more enforcement, VM could only be > > destroyed after all assigned CC vPCI devices are destroyed. > > And KVM destroys the VM? Yes. > > > Nowadays, VFIO already holds KVM reference, so we need > > > > close(vfio_fd) > > -> iommufd_device_detach_vdev() > > This doesn't happen though, it destroys the normal device (idev) which > the vdevice is stacked on top of. You'd have to make normal device > destruction trigger vdevice destruction > > > -> tsm_tdi_unbind() > > -> tdi stop > > -> callback to VFIO, dmabuf_move_notify(revoke) > > -> KVM unmap MMIO > > -> tdi metadata remove > > This omits the viommu. It won't get destroyed until the iommufd > closes, so iommufd will be holding the kvm and it will do the final > put. I see. https://lore.kernel.org/all/20250319233111.ge126...@ziepe.ca/ Thanks, Yilun > > Jason
