RE: [PATCH v10 04/12] iommu: Add attach/detach_dev_pasid iommu interface

[Tian, Kevin]

> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
> 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;
> +}