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