> From: Williams, Dan J <dan.j.williams@xxxxxxxxx> > Sent: Friday, September 6, 2024 4:53 AM > > Jason Gunthorpe wrote: > > On Thu, Sep 05, 2024 at 12:17:14PM +0000, Tian, Kevin wrote: > > > Then you expect to build CC/vPCI stuff around the vIOMMU > > > object given it already connects to KVM? > > > > Yes, it is my thought > > > > We alreay have a binding of devices to the viommu, increasing that to > > also include creating vPCI objects in the trusted world is a small > > step. > > Sounds reasonable to me. > > To answer Kevin's question about what "bind capable" means I need to > clarify this oversubscribed "bind" term means. "Bind" in the TDISP sense > is transitioning the device to the LOCKED state so that its > configuration is static and ready for the VM to run attestation without > worrying about TOCTOU races. > > The VMM is not in a good position to know when the assigned device can > be locked. There are updates, configuration changes, and reset/recovery > scenarios the VM may want to perform before transitioning the device to > the LOCKED state. So, the "bind capable" concept is: pre-condition VFIO > with the context that "this vPCI device is known to VFIO as a device > that can attach to the secure world, all the linkage between VFIO and > the secure world is prepared for a VM to trigger entry into the LOCKED > state, and later the RUN state". Okay this makes sense. So the point is that the TDI state machine is fully managed by the TSM driver so here 'bind capable' is a necessary preparation step for that state machine to enter the LOCKED state. > > As mentioned in another thread this entry into the LOCKED state is > likely nearly as violent as hotplug event since the DMA layer currently > has no concept of a device having a foot in the secure world and the > shared world at the same time. Is the DMA layer relevant in this context? Here we are talking about VFIO/IOMMUFD which can be hinted by VMM for whatever side effect caused by the entry into the LOCKED state...
