On Thu, Dec 11, 2025 at 6:57 PM Yi Liu <[email protected]> wrote: > > On 2025/12/11 16:22, Jason Wang wrote: > > On Mon, Nov 17, 2025 at 5:38 PM Zhenzhong Duan <[email protected]> > > 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 <[email protected]> > >> Signed-off-by: Zhenzhong Duan <[email protected]> > >> --- > > > > 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 <[email protected]> > 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/[email protected] > Reviewed-by: Jason Gunthorpe <[email protected]> > Reviewed-by: Kevin Tian <[email protected]> > Reviewed-by: Nicolin Chen <[email protected]> > Reviewed-by: Lu Baolu <[email protected]> > Signed-off-by: Yi Liu <[email protected]> > Tested-by: Nicolin Chen <[email protected]> > Signed-off-by: Jason Gunthorpe <[email protected]> > > 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 >
