Re: [PATCH v8 06/12] iommufd: Support pasid attach/replace

[Baolu Lu <baolu.lu@linux.intel.com>]

On 2/26/25 19:40, Yi Liu wrote:
> This introduces three APIs for device drivers to manage pasid attach/
> replace/detach.
> 
>      int iommufd_device_pasid_attach(struct iommufd_device *idev,
> 				    ioasid_t pasid, u32 *pt_id);
>      int iommufd_device_pasid_replace(struct iommufd_device *idev,
> 				     ioasid_t pasid, u32 *pt_id);
>      void iommufd_device_pasid_detach(struct iommufd_device *idev,
> 				     ioasid_t pasid);
> 
> The pasid operations share underlying attach/replace/detach infrastructure
> with the device operations, but still have some different implications:
> 
>   - no reserved region per pasid otherwise SVA architecture is already
>     broken (CPU address space doesn't count device reserved regions);
> 
>   - accordingly no sw_msi trick;
> 
> Cache coherency enforcement is still applied to pasid operations since
> it is about memory accesses post page table walking (no matter the walk
> is per RID or per PASID).
> 
> Since the attach is per PASID, this introduces a pasid_hwpts xarray to
> track the per-pasid attach data.

I feel that this is somewhat redundant with the pasid xarray in
iommu_group. If iommu_replace_device_pasid_handle() were modified to
include the old domain that was assigned to the PASID, the following
patch would be unnecessary?

https://lore.kernel.org/linux-iommu/20250226011849.5102-4-yi.l.liu@intel.com/

> 
> AMD requires using PASID-compatible domains for PASIDs, hence the hwpts
> directing the PASID path requires to flagged with IOMMU_HWPT_ALLOC_PASID.
> 
> Signed-off-by: Kevin Tian<kevin.tian@intel.com>
> Signed-off-by: Yi Liu<yi.l.liu@intel.com>

Either way,

Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>