[PATCH] iommu/arm-smmu-v3: Allow stream table to have nodes with the same ID

Nicolin Chen nicolinc at nvidia.com
Fri Apr 11 16:33:44 PDT 2025


On Fri, Apr 11, 2025 at 04:13:01PM +0100, Robin Murphy wrote:
> On 11/04/2025 5:47 am, Nicolin Chen wrote:
> > From: Jason Gunthorpe <jgg at nvidia.com>
> > 
> > ASPEED VGA card has two built-in devices:
> >   0008:06:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge (rev 06)
> >   0008:07:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 52)
> > 
> > Its toplogy looks like this:
> >   +-[0008:00]---00.0-[01-09]--+-00.0-[02-09]--+-00.0-[03]----00.0  Sandisk Corp Device 5017
> >                               |               +-01.0-[04]--
> >                               |               +-02.0-[05]----00.0  NVIDIA Corporation Device
> >                               |               +-03.0-[06-07]----00.0-[07]----00.0  ASPEED Technology, Inc. ASPEED Graphics Family
> >                               |               +-04.0-[08]----00.0  Renesas Technology Corp. uPD720201 USB 3.0 Host Controller
> >                               |               \-05.0-[09]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
> >                               \-00.1  PMC-Sierra Inc. Device 4028
> > 
> > Being a legacy PCI device that does not have RID on the wire, the system
> > does not preserve a RID for that PCI bridge (0008:06), so the IORT code
> > has to dma alias for iort_pci_iommu_init() via pci_for_each_dma_alias(),
> > resulting in both of them getting the same Stream ID.
> 
> Hmm, actually, this doesn't even make a whole heap of sense, and it's
> not what's happening here at all.
> 
> The bridge *does* claim its own RID, and per the aliasing rules the
> devices behind it claim both their own RID and the alias to function
> 00.0 on the bridge's secondary bus, like so in action:

Yea, I just found out that the bridge does have a different SID.
It was actually the VGA controller itself having two fwspec->ids
populated by the IORT code. Then, the SMMU driver allocated two
separate streams with the same set of device pointer and SID:
  pci 0008:06:00.0: arm_smmu_insert_master: fwspec index=0, sid=0x10600
  pci 0008:06:00.0: Adding to iommu group 21
  pci 0008:07:00.0: arm_smmu_insert_master: fwspec index=0, sid=0x10700
  pci 0008:07:00.0: arm_smmu_insert_master: fwspec index=1, sid=0x10700
  pci 0008:07:00.0: Adding to iommu group 21

Perhaps the duplicated fwspec->id should be avoided in the IORT
code at the first place v.s. bypassing the fwspec->ids[1]?

Thanks
Nicolin



More information about the linux-arm-kernel mailing list