> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Saturday, February 25, 2023 8:28 AM > [...] > The implementation is complicated because we have to introduce some > per-iommu_group memory in iommufd and redo how we think about multi- > device > groups to be more explicit. This solves all the locking problems in the > prior attempts. > Now think about the pasid case. pasid attach is managed as a device operation today: iommu_attach_device_pasid() Following it naturally we'll have a pasid array per iommufd_device to track attached HWPT per pasid. But internally there is only one pasid table per iommu group. i.e. same story as RID attach that once dev1 replaces hwpt on pasid1 then it takes effect on all other devices in the same group. Then confusion comes. If we must have explicit group object in iommufd to manage domain replacement per rid, then do we need the same explicit mechanism e.g. tracking pasid attached hwpt in iommufd_group instead of in iommufd_device? and have a iommu_attach_group_pasid() API. In contrast if it's fine to continue managing pasid attach/replace per device, does it imply there is another way of solving it cleanly w/o explicit group object in the rid case? Thanks Kevin
