Re: [PATCH v8 02/23] intel_iommu: Delete RPS capability related supporting code

[Yi Liu <yi.l.liu@intel.com>]

On 2025/12/11 16:22, Jason Wang wrote:
> On Mon, Nov 17, 2025 at 5:38 PM Zhenzhong Duan <zhenzhong.duan@intel.com> wrote:
>>
>> RID-PASID Support(RPS) is not set in vIOMMU ECAP register, the supporting
>> code is there but never takes effect.
>>
>> Meanwhile, according to VTD spec section 3.4.3:
>> "Implementations not supporting RID_PASID capability (ECAP_REG.RPS is 0b),
>> use a PASID value of 0 to perform address translation for requests without
>> PASID."
>>
>> We should delete the supporting code which fetches RID_PASID field from
>> scalable context entry and use 0 as RID_PASID directly, because RID_PASID
>> field is ignored if no RPS support according to spec.
>>
>> This simplifies the code and doesn't bring any penalty.
>>
>> Suggested-by: Yi Liu <yi.l.liu@intel.com>
>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>> ---
> 
> Is the feature deprecated in the spec? If not, it should be still
> better to enable it.

Hi Jason,

The feature is still in the spec. However, using PASID#0 for the
requests without pasid is aligned across vendors. So the linux iommu
subsystem uses PASID#0 to differentiate the pasid path and non-pasid
path like below:

commit bc06f7f66de404ae6323963361fe4e2f5f71a1e5
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Fri Mar 21 10:19:26 2025 -0700

     iommufd/device: Only add reserved_iova in non-pasid path

     As the pasid is passed through the attach/replace/detach helpers, it is
     necessary to ensure only the non-pasid path adds reserved_iova.

     Link: 
https://patch.msgid.link/r/20250321171940.7213-5-yi.l.liu@intel.com
     Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
     Reviewed-by: Kevin Tian <kevin.tian@intel.com>
     Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
     Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
     Signed-off-by: Yi Liu <yi.l.liu@intel.com>
     Tested-by: Nicolin Chen <nicolinc@nvidia.com>
     Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
index 7051feda2fab..4625f084f7d0 100644
--- a/drivers/iommu/iommufd/device.c
+++ b/drivers/iommu/iommufd/device.c
@@ -483,6 +483,7 @@ int iommufd_hw_pagetable_attach(struct 
iommufd_hw_pagetable *hwpt,
                                 struct iommufd_device *idev, ioasid_t 
pasid)
  {
         struct iommufd_hwpt_paging *hwpt_paging = find_hwpt_paging(hwpt);
+       bool attach_resv = hwpt_paging && pasid == IOMMU_NO_PASID;
         int rc;


So even though intel hardware report RPS=1, the linux intel iommu
driver uses PASID#0 as rid_pasid and ignores the RPS value. So
I don't think we will ever report RPS=1 to VM. Also, as Zhenzhong's
commit message states, current vIOMMU does not report RPS, the logic to
retrieve rid_pasid from context entry is not necessary as well. Based on
the fact, I think it is nice to drop the support. Please let us know if
you have other ideas.

Regards,
Yi Liu