On Wed, Jan 22, 2025 at 08:55:12AM -0400, Jason Gunthorpe wrote: > On Wed, Jan 22, 2025 at 12:32:56PM +0800, Xu Yilun wrote: > > On Tue, Jan 21, 2025 at 01:43:03PM -0400, Jason Gunthorpe wrote: > > > On Tue, Jun 25, 2024 at 05:12:10AM +0800, Xu Yilun wrote: > > > > > > > When VFIO works as a TEE user in VM, it means an attester (e.g. PCI > > > > subsystem) has already moved the device to RUN state. So VFIO & DPDK > > > > are all TEE users, no need to manipulate TDISP state between them. > > > > AFAICS, this is the most preferred TIO usage in CoCo-VM. > > > > > > No, unfortunately. Part of the motivation to have the devices be > > > unlocked when the VM starts is because there is an expectation that a > > > driver in the VM will need to do untrusted operations to boot up the > > > > I assume these operations are device specific. > > Yes > > > > device before it can be switched to the run state. > > > > > > So any vfio use case needs to imagine that VFIO starts with an > > > untrusted device, does stuff to it, then pushes everything through to > > > > I have concern that VFIO has to do device specific stuff. Our current > > expectation is a specific device driver deals with the untrusted > > operations, then user writes a 'bind' device sysfs node which detaches > > the driver for untrusted, do the attestation and accept, and try match > > the driver for trusted (e.g. VFIO). > > I don't see this as working, VFIO will FLR the device which will > destroy anything that was done prior. > > VFIO itself has to do the sequence and the VFIO userspace has to > contain the device specific stuff. I don't have a complete idea yet. But the goal is not to make any existing driver seamlessly work with secure device. It is to provide a generic way for bind/attestation/accept, and may save driver's effort if they don't care about this startup process. There are plenty of operations that a driver can't do to a secure device, FLR is one of them. The TDISP SPEC has described some general rules but some are even device specific. So I think a driver (including VFIO) expects change to support trusted device, but may not have to cover bind/attestation/accept flow. Thanks, Yilun > > The bind/unbind dance for untrusted->trusted would need to be > internalized in VFIO without unbinding. The main motivation for the > bind/unbind flow was to manage the DMA API, which VFIO does not use. > > Jason
