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.

...

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)

...

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?

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.

Jason