On Thu, Mar 06, 2025 at 02:26:14PM -0400, Jason Gunthorpe wrote: > On Thu, Mar 06, 2025 at 02:47:23PM +0800, Xu Yilun wrote: > > > While for AMD: > > ... > > b.guest_device_id = guest_rid; //TDI ID, it is the vBDF > > b.gctx_paddr = gctx_paddr; //AMDs CoCo-VM ID > > > > ret = sev_tio_do_cmd(SEV_CMD_TIO_TDI_BIND, &b, ... > > > > > > Neither of them use vIOMMU ID or any IOMMU info, so the only concern is > > vBDF. > > I think that is enough, we should not be putting this in VFIO if it > cannot execute it for AMD :\ OK. With these discussion, my understanding is it can execute for AMD but we don't duplicate the effort for vdevice->id. We can swtich to vdevice and try to solve the rest problems. > > > > You could also issue the TSM bind against the idev on the iommufd > > > side.. > > > > But I cannot figure out how idev could ensure no mmap on VFIO, and how > > idev could call dma_buf_move_notify. > > I suggest you start out this way from the VFIO. Put the device in a CC > mode which bans the mmap entirely and pass that CC capable as a flag > into iommufd when creating the idev. IIUC, it basically switches back to my previous implementation for mmap. https://lore.kernel.org/kvm/20250107142719.179636-9-yilun.xu@xxxxxxxxxxxxxxx/ I can do that. Thanks, yilun > > If it really needs to be dyanmic a VFIO feature could change the CC > mode and that could call back to iommufd to synchronize if that is > allowed. > > Jason
