Re: [RFC PATCH v2 14/22] iommufd: Add TIO calls

[Dan Williams <dan.j.williams@intel.com>]

Jason Gunthorpe wrote:
> On Wed, Feb 26, 2025 at 11:12:32AM +1100, Alexey Kardashevskiy wrote:
> > > I still have concern about the vdevice interface for bind. Bind put the
> > > device to LOCKED state, so is more of a device configuration rather
> > > than an iommu configuration. So seems more reasonable put the API in VFIO?
> > 
> > IOMMUFD means pretty much VFIO (in the same way "VFIO means KVM" as 95+% of
> > VFIO users use it from KVM, although VFIO works fine without KVM) so not
> > much difference where to put this API and can be done either way. VFIO is
> > reasonable, the immediate problem is that IOMMUFD's vIOMMU knows the guest
> > BDFn (well, for AMD) and VFIO PCI does not.
> 
> I would re-enforce what I said before, VFIO & iommufd alone should be
> able to operate a TDISP device and get device encrpytion without
> requiring KVM.

Without requiring KVM, but still requiring a TVM context per TDISP
expectations?

I.e. I am still trying to figure out if you are talking about
device-authentication and encryption without KVM, TDISP without a
TVM (not sure what that is), or TDISP state management relative to a
shared concept of a "TVM context" that KVM also references.

> It makes sense that if the secure firmware object handles (like the
> viommu, vdevice, vBDF) are accessed through iommufd then iommufd will
> relay operations against those handles.

Yes, that tracks.