RE: [PATCH 1/1] iommu/vt-d: Fix WARN_ON in iommu probe path

[Tian, Kevin]

+Bjorn

> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
> Sent: Monday, April 8, 2024 3:15 PM
> 
> On 2024/4/8 11:52, Tian, Kevin wrote:
> >> From: Lu Baolu<baolu.lu@xxxxxxxxxxxxxxx>
> >> Sent: Sunday, April 7, 2024 9:14 AM
> >>
> >> Commit 1a75cc710b95 ("iommu/vt-d: Use rbtree to track iommu probed
> >> devices") adds all devices probed by the iommu driver in a rbtree
> >> indexed by the source ID of each device. It assumes that each device
> >> has a unique source ID. This assumption is incorrect and the VT-d
> >> spec doesn't state this requirement either.
> >>
> >> The reason for using a rbtree to track devices is to look up the device
> >> with PCI bus and devfunc in the paths of handling ATS invalidation time
> >> out error and the PRI I/O page faults. Both are PCI ATS feature related.
> >>
> >> Only track the devices that have PCI ATS capabilities in the rbtree to
> >> avoid unnecessary WARN_ON in the iommu probe path. Otherwise, on
> some
> >> platforms below kernel splat will be displayed and the iommu probe
> results
> >> in failure.
> > Just be curious. What about two ATS capable devices putting behind
> > a PCI-to-PCIe bridge?
> 
> I don't think ATS capable device putting behind a PCI-to-PCIe bridge is
> a right configuration for the ATS service. The PCIe spec requires this
> in section 10.1.1, that
> 
> "
> ATS requires the following:
> - ATS capable components must interoperate with [PCIe-1.1] compliant
>    components.
> ...
> "
> 
> My understanding is that PCI-to-PCIe bridge is not a PCIe compliant
> device.
> 

what is the pci core policy on such device? pci_enable_ats() doesn't
prevent such device and I saw various places in pci core do handle
the PCI_EXP_TYPE_PCIE_BRIDGE type...