Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH 1/1] iommu/vt-d: Fix WARN_ON in iommu probe path | Date | Mon, 8 Apr 2024 09:12:11 +0000 |
| |
+Bjorn
> From: Baolu Lu <baolu.lu@linux.intel.com> > Sent: Monday, April 8, 2024 3:15 PM > > On 2024/4/8 11:52, Tian, Kevin wrote: > >> From: Lu Baolu<baolu.lu@linux.intel.com> > >> 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...
| |