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: 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 > 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. Jason
