[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