On 15/3/25 12:11, Dan Williams wrote:
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),
It is about accessing MMIO with Cbit set, and running DMA to/from
private memory, in DPDK. On AMD, if we want the PCI's Tbit in MMIO, the
Cbit needs to be set in some page table. "TVM" in this case is a few
private pages (+ bunch of PSP calls to bring to the right state)
pretending to be a CVM which does not need to run. Thanks,
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.
--
Alexey
