Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH v10 04/12] iommu: Add attach/detach_dev_pasid iommu interface | Date | Fri, 29 Jul 2022 02:56:24 +0000 |
| |
> From: Baolu Lu <baolu.lu@linux.intel.com> > Sent: Friday, July 29, 2022 10:49 AM > > On 2022/7/28 19:59, Jason Gunthorpe wrote: > > On Thu, Jul 28, 2022 at 03:06:47AM +0000, Tian, Kevin wrote: > > > >>> Then we don't need this weirdo check in the core iommu code at all. > >> > >> and then we could also move group->pasid_array to device->pasid_array > >> with this approach. Though the end result doesn't change i.e. still only > >> the singleton group can enable pasid the iommu core can just stick to > >> the device manner now. > > > > I don't see why, the group is still logically the unit of attachment > > in the iommu area, and if we have a multi-device group it just means > > we iterate over all the devices in the group when doing pasid set, no > > different than a RID. > > Okay. Based on the discussions in this thread, this patch will evolve to > look like below. Any comments or concerns? > ... > +static bool iommu_group_device_pasid_viable(struct iommu_group *group, > + struct device *dev) > +{ > + int count; > + > + count = iommu_group_device_count(group); > + if (count != 1) > + return false; > + > + /* > + * Block PASID attachment in cases where the PCI fabric is > + * routing based on address. PCI/ACS disables that. > + */ > + if (dev_is_pci(dev)) > + return pci_acs_path_enabled(to_pci_dev(dev), NULL, > + REQ_ACS_FLAGS);
I think we are leaning toward doing above check in pci_enable_pasid(). Then no singleton check inside iommu core.
Presumably similar check can be done in DT/ACPI path of enabling pasid?
> + > + /* > + * Otherwise, the device came from DT/ACPI, assume it is static and > + * then singleton can know from the device count in the group. > + */ > + return true; > +}
| |