Jason Gunthorpe wrote: > On Wed, Aug 28, 2024 at 05:00:57PM -0700, Dan Williams wrote: > > Jason Gunthorpe wrote: > > [..] > > > So when I look at the spec I think that probably TIO_DEV_* should be > > > connected to VFIO, somewhere as vfio/kvm/iommufd ioctls. This needs to > > > be coordinated with everyone else because everyone has *some kind* of > > > "trusted world create for me a vPCI device in the secure VM" set of > > > verbs. > > > > > > TIO_TDI is presumably the device authentication stuff? > > > > I would expect no, because device authentication is purely a > > physical-device concept, and a TDI is some subset of that device (up to > > and including full physical-function passthrough) that becomes VM > > private-world assignable. > > So I got it backwards then? The TDI is the vPCI and DEV is the way to > operate TDISP/IDE/SPDM/etc? Spec says: Right. > > To use a TDISP capable device with SEV-TIO, host software must first > arrange for the SEV firmware to establish a connection with the device > by invoking the TIO_DEV_CONNECT > command. The TIO_DEV_CONNECT command performs the following: > > * Establishes a secure SPDM session using Secured Messages for SPDM. > * Constructs IDE selective streams between the root complex and the device. > * Checks the TDISP capabilities of the device. > > Too many TLAs :O My favorite is that the spec calls the device capability "TEE I/O" but when you are speaking it no one can tell if you are talking about "TEE I/O" the generic PCI thing, or "TIO", the AMD-specific seasoning on top of TDISP. > > I agree with this. There is a definite PCI only / VFIO-independent > > portion of this that is before any consideration of TDISP LOCKED and RUN > > states. It only deals with PCI device-authentication, link encryption > > management, and is independent of any confidential VM. Then there is the > > whole "assignable device" piece that is squarely KVM/VFIO territory. > > Yes > > > Theoretically one could stop at link encryption setup and never proceed > > with the rest. That is, assuming the platform allows for IDE protected > > traffic to flow in the "T=0" (shared world device) case. > > Yes. I keep hearing PCI people talking about interesting use cases for > IDE streams independent of any of the confidential compute stuff. I > think they should not be tied together. I encourage those folks need to read the actual hardware specs, not just the PCI spec. As far as I know there is only one host platform implementation that allows IDE establishment and traffic flow for T=0 cases. So it is not yet trending to be a common thing that the PCI core can rely upon.
