On Wed, Jul 10, 2024 at 08:24:16AM +0000, Tian, Kevin wrote: > > From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > > Sent: Friday, June 28, 2024 4:56 PM > > > > This splits the preparation works of the iommu and the Intel iommu driver > > out from the iommufd pasid attach/replace series. [1] > > > > To support domain replacement, the definition of the set_dev_pasid op > > needs to be enhanced. Meanwhile, the existing set_dev_pasid callbacks > > should be extended as well to suit the new definition. > > > > pasid attach/replace is mandatory on Intel VT-d given the PASID table > > locates in the physical address space hence must be managed by the kernel, > > both for supporting vSVA and coming SIOV. But it's optional on ARM/AMD > > which allow configuring the PASID/CD table either in host physical address > > space or nested on top of an GPA address space. This series only extends > > the Intel iommu driver as the minimal requirement. > > Looks above is only within VFIO/IOMMUFD context (copied from the old > series). But this series is all in IOMMU and pasid attach is certainly not > optional for SVA on all platforms. this needs to be revised. I feel like we should explicitly block replace on AMD by checking if old_domain is !NULL and failing. Then the description is sort of like Replace is useful for iommufd/VFIO to provide perfect HW emulation in case the VM is expecting to be able to change a PASID on the fly. As AMD will only support PASID in VM's using nested translation where we don't use the set_dev_pasid API leave it disabled for now. Jason
