Re: [PATCH v2 03/16] iommu: Compute iommu_groups properly for PCIe switches

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Jul 18, 2025 at 03:00:28PM -0400, Donald Dutile wrote:
> > > > +	/*
> > > > +	 * !self is only for SRIOV virtual busses which should have been
> > > > +	 * excluded above.
> > > by pci_is_root_bus() ?? -- that checks if bus->parent exists...
> > > not sure how that excludes the case of !bus->self ...
> > 
> > Should be this:
> > 
> > 	/*
> > 	 * !self is only for SRIOV virtual busses which should have been
> > 	 * excluded by pci_physfn()
> > 	 */
> > 	if (WARN_ON(!bus->self))
> > 
> my Linux tree says its this:
> static inline bool pci_is_root_bus(struct pci_bus *pbus)
> {
>         return !(pbus->parent);
> }
> 
> is there a change to pci_is_root_bus() in a -next branch?

Not that, at the start of the function there is a pci_physfn(), the
entire function never works on a VF, so bus is never a VF's bus.

> > > > +	 */
> > > > +	if (WARN_ON(!bus->self))
> > > > +		return ERR_PTR(-EINVAL);
> > > > +
> > > > +	group = iommu_group_get(&bus->self->dev);
> > > > +	if (!group) {
> > > > +		/*
> > > > +		 * If the upstream bridge needs the same group as pdev then
> > > > +		 * there is no way for it's pci_device_group() to discover it.
> > > > +		 */
> > > > +		dev_err(&pdev->dev,
> > > > +			"PCI device is probing out of order, upstream bridge device of %s is not probed yet\n",
> > > > +			pci_name(bus->self));
> > > > +		return ERR_PTR(-EPROBE_DEFER);
> > > > +	}
> > > > +	if (group->bus_data & BUS_DATA_PCI_NON_ISOLATED)
> > > > +		return group;
> > > > +	iommu_group_put(group);
> > > > +	return NULL;
> > > ... and w/o the function description, I don't follow:
> > > -- rtn an iommu-group if it has NON_ISOLATED property ... but rtn null if all devices below it are isolated?
> > 
> > Yes. For all these internal functions non null means we found a group
> > to join, NULL means to keep checking isolation rules.
> > 
> ah, so !group == keep looking for for non-isolated conditions.. got it.
> Could that lead to two iommu-groups being created that could/should be one larger one?

The insistence on doing things in order should prevent that from
happening. So long as the larger group is present in the upstream
direction, or within the current bus, then it can be joined up.

This doesn't work if it randomly applies to PCI devices, it is why the
above has added the "PCI device is probing out of order" detection.

Jason