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

[Jason Wang <jasowang@redhat.com>]

On Thu, Dec 11, 2025 at 6:57 PM Yi Liu <yi.l.liu@intel.com> wrote:
>
> 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.

Probably, but we need to support OSes other than Linux.

> 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.

I'm fine to drop that, just want to double check if it's worth keeping
with an option to enable it.

Thanks

>
> Regards,
> Yi Liu
>