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.
