On 2025/3/20 01:58, Nicolin Chen wrote:
On Thu, Mar 13, 2025 at 05:47:52AM -0700, Yi Liu wrote:
PASID usage requires PASID support in both device and IOMMU. Since the
iommu drivers always enable the PASID capability for the device if it
is supported, this extends the IOMMU_GET_HW_INFO to report the PASID
capability to userspace. Also, enhances the selftest accordingly.
Overall, I am a bit confused by the out_capabilities field in the
IOMMU_GET_HW_INFO. Why these capabilities cannot be reported via
the driver specific data structure?
E.g. we don't report the "NESTING" capability in out_capabilities
at all and that works fine since the iommu driver would reject if
it doesn't support.
NESTING is a bit different. Userspace needs to know underlying PASID
cap and further expose it to guest if it wants. While NESTING is not
from this angle. It's just for the use of userspace. So a try and fail
is ok.
Mind elaborate the reason for these two new capabilities? What is
the benefit from keeping them in the core v.s. driver level?
I view the PASID cap is generic just like the DIRTY_TRACKING cap.
Reporting them in the driver-specific part is fine, but I doubt
if it is better since PASID cap is generic to all vendors.
(sorry for doubting this at such a late stage...)
Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
Reviewed-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
Tested-by: Zhangfei Gao <zhangfei.gao@xxxxxxxxxx> #aarch64 platform
Signed-off-by: Yi Liu <yi.l.liu@xxxxxxxxx>
---
drivers/iommu/iommufd/device.c | 35 +++++++++++++++++++++++++++++++++-
drivers/pci/ats.c | 33 ++++++++++++++++++++++++++++++++
include/linux/pci-ats.h | 3 +++
include/uapi/linux/iommufd.h | 14 +++++++++++++-
4 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
index 70da39f5e227..1f3bec61bcf9 100644
--- a/drivers/iommu/iommufd/device.c
+++ b/drivers/iommu/iommufd/device.c
@@ -3,6 +3,8 @@
*/
#include <linux/iommu.h>
#include <linux/iommufd.h>
+#include <linux/pci.h>
+#include <linux/pci-ats.h>
"pci-ats" includes "pci.h" already.
yes, it is.
--
Regards,
Yi Liu
