>-----Original Message----- >From: Jason Wang <[email protected]> >Subject: Re: [PATCH v8 02/23] intel_iommu: Delete RPS capability related >supporting code > >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.
IIUC, existing qemu doesn't expose RPS cap, a working OS with existing qemu should also work after this patch, because it should always choose PAISD_0 for rid_pasid. > >> 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. I think no need, enabling it doesn't make qemu compatible with more OSes. An OS supporting RPS cap should already follow VTD spec and support without RPS cap. Thanks Zhenzhong
