On 6/5/24 4:23 PM, Tian, Kevin wrote:
From: Lu Baolu <baolu.lu@xxxxxxxxxxxxxxx> Sent: Monday, May 27, 2024 12:05 PM @@ -249,6 +249,12 @@ enum iommu_cap { */ IOMMU_CAP_DEFERRED_FLUSH, IOMMU_CAP_DIRTY_TRACKING, /* IOMMU supports dirty tracking */ + /* + * IOMMU driver supports user-managed IOASID table. There is no + * user domain for each PASID and the I/O page faults are forwarded + * through the user domain attached to the device RID. + */ + IOMMU_CAP_USER_IOASID_TABLE, };Given all other context are around PASID let's just call it as USER_PASID_TABLE. btw this goes differently from your plan in [1] which tried to introduce different nesting types between Intel and other vendors. I guess the reason might be that you want to avoid getting the handle for RID on Intel platform in case of failing to find the handle for the faulting PASID. and save a new domain type. this looks fine to me but should be explained.
Yeah! I was considering this in two aspects and chose this simple solution in the end. - If we choose to add a new domain type, we need to change iommufd, iommu core and the individual driver. That seems too complicated to address a small issue here. - Fundamentally, this is a hardware implementation difference, hence use the existing per-device iommu capability interface sounds more reasonable.
[1] https://lore.kernel.org/linux-iommu/0de7c71f-571a-4800-8f2b-9eda0c6b75de@xxxxxxxxxxxxxxx/
Best regards, baolu
