> From: Williams, Dan J <dan.j.williams@xxxxxxxxx> > Sent: Wednesday, September 4, 2024 9:00 AM > > Jason Gunthorpe wrote: > > On Tue, Sep 03, 2024 at 01:34:29PM -0700, Dan Williams wrote: > > > Jason Gunthorpe wrote: > > > > On Fri, Aug 30, 2024 at 01:20:12PM +0800, Xu Yilun wrote: > > > > > > > > > > If that is true for the confidential compute, I don't know. > > > > > > > > > > For Intel TDX TEE-IO, there may be a different story. > > > > > > > > > > Architechturely the secure IOMMU page table has to share with KVM > secure > > > > > stage 2 (SEPT). The SEPT is managed by firmware (TDX Module), TDX > Module > > > > > ensures the SEPT operations good for secure IOMMU, so there is no > much > > > > > trick to play for SEPT. > > > > > > > > Yes, I think ARM will do the same as well. > > > > > > > > From a uAPI perspective we need some way to create a secure vPCI > > > > function linked to a KVM and some IOMMUs will implicitly get a > > > > translation from the secure world and some IOMMUs will need to > manage > > > > it in untrusted hypervisor memory. > > > > > > Yes. This matches the line of though I had for the PCI TSM core > > > interface. > > > > Okay, but I don't think you should ever be binding any PCI stuff to > > KVM without involving VFIO in some way. > > > > VFIO is the security proof that userspace is even permitted to touch > > that PCI Device at all. > > Right, I think VFIO grows a uAPI to make a vPCI device "bind capable" > which ties together the PCI/TSM security context, the assignable device > context and the KVM context. > Could you elaborate why the new uAPI is for making vPCI "bind capable" instead of doing the actual binding to KVM?
