Hi Yi, On 10/18/2024 11:28 AM, Yi Liu wrote: > During the review of iommufd pasid series, Kevin and Jason suggested > attaching PASID to the blocked domain hence replacing the usage of > remove_dev_pasid() op [1]. This makes sense as it makes the PASID path > aligned with the RID path which attaches the RID to the blocked_domain > when it is to be blocked. To do it, it requires passing the old domain > to the iommu driver. This has been done in [2]. I understand attaching RID to blocked_domain. But I am not getting why we have to do same for PASID. In remove_dev_pasid() path we clear the entry in PASID table (AMD case GCR3 table). So no further access is allowed anyway. Is it just to align with RID flow -OR- do we have any other reason? -Vasant > > This series makes the Intel iommu driver and ARM SMMUv3 driver support > attaching PASID to the blocked domain. While the AMD iommu driver does > not have the blocked domain yet, so still uses the remove_dev_pasid() op. > > [1] https://lore.kernel.org/linux-iommu/20240816130202.GB2032816@xxxxxxxxxx/ > [2] https://lore.kernel.org/linux-iommu/20241018055402.23277-2-yi.l.liu@xxxxxxxxx/ > > v2: > - Add Kevin's r-b > - Adjust the order of patch 03 of v1, it should be the first patch (Baolu) > > v1: https://lore.kernel.org/linux-iommu/20240912130653.11028-1-yi.l.liu@xxxxxxxxx/ > > Regards, > Yi Liu > > Jason Gunthorpe (1): > iommu/arm-smmu-v3: Make the blocked domain support PASID > > Yi Liu (2): > iommu: Add a wrapper for remove_dev_pasid > iommu/vt-d: Make the blocked domain support PASID > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 12 ++++----- > drivers/iommu/intel/iommu.c | 19 ++++++++----- > drivers/iommu/intel/pasid.c | 3 ++- > drivers/iommu/iommu.c | 30 ++++++++++++++++----- > 4 files changed, 45 insertions(+), 19 deletions(-) >
