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. > This is why I picked on tsm_dev_connect_store().. > > > Besides sysfs, the module provides common "verbs" to be defined by the > > platform (which is right now a reduced set of the AMD PSP operations but the > > hope is it can be generalized); and the module also does PCIe DOE bouncing > > (which is also not uncommon). Part of this exercise is trying to find some > > common ground (if it is possible), hence routing everything via this module. > > I think there is a seperation between how the internal stuff in the > kernel works and how/what the uAPIs are. > > General stuff like authenticate/accept/authorize a PCI device needs > to be pretty cross platform. > > Stuff like creating vPCIs needs to be ioctls linked to KVM/VFIO > somehow and can have more platform specific components. > > I would try to split your topics up more along those lines.. 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. 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.
