On Thu, Mar 20, 2025 at 03:32:54PM +0000, Robin Murphy wrote:
> Much like arm-smmu in commit 7d835134d4e1 ("iommu/arm-smmu: Make
> instance lookup robust"), virtio-iommu appears to have the same issue
> where iommu_device_register() makes the IOMMU instance visible to other
> API callers (including itself) straight away, but internally the
> instance isn't ready to recognise itself for viommu_probe_device() to
> work correctly until after viommu_probe() has returned. This matters a
> lot more now that bus_iommu_probe() has the DT/VIOT knowledge to probe
> client devices the way that was always intended. Tweak the lookup and
> initialisation in much the same way as for arm-smmu, to ensure that what
> we register is functional and ready to go.
>
> Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path")
> Signed-off-by: Robin Murphy <robin.mur...@arm.com>
> ---
>
> Pre-emptive fix by inspection...
I get the warning introduced by bcb81ac6ae3c with DT boot, but this patch
doesn't remove it:
[ 1.463193] igb 0000:00:03.0: late IOMMU probe at driver bind, something
fishy here!
[ 1.464265] WARNING: CPU: 3 PID: 1 at drivers/iommu/iommu.c:446
iommu_init_device+0xdc/0x300
[ 1.468885] Modules linked in:
[ 1.469835] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted
6.14.0-rc7-00005-g18abf92a52cf #2120
[ 1.470170] Hardware name: linux,dummy-virt (DT)
[ 1.470441] pstate: 61000005 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 1.470692] pc : iommu_init_device+0xdc/0x300
[ 1.470808] lr : iommu_init_device+0xdc/0x300
[ 1.470920] sp : ffff80008278b970
[ 1.471022] x29: ffff80008278b980 x28: 0000000000000000 x27: 0000000000000000
[ 1.471382] x26: 0000000000000000 x25: ffff800081f49960 x24: 0000000000000000
[ 1.471557] x23: ffff0000c156b0c8 x22: ffff8000826f4930 x21: ffff8000826f4928
[ 1.471861] x20: ffff80008248d878 x19: ffff80008248c8c8 x18: 0000000000000006
[ 1.472046] x17: ffff800082489500 x16: 00000000f8a49ce1 x15: ffff80008278b52f
[ 1.472223] x14: ffff80008278b340 x13: ffff80010278b527 x12: ffff80008228d478
[ 1.472396] x11: ffff8000821dd4d0 x10: ffff80008228d4d0 x9 : ffff80008018908c
[ 1.472597] x8 : 0000000000000001 x7 : 000000000002ffe8 x6 : c0000000ffffdfff
[ 1.472773] x5 : 00000000000affa8 x4 : 0000000000000000 x3 : 0000000000000000
[ 1.472948] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c03fc500
[ 1.473220] Call trace:
[ 1.473478] iommu_init_device+0xdc/0x300 (P)
[ 1.473723] __iommu_probe_device+0x48/0x208
[ 1.473859] iommu_probe_device+0x3c/0x88
[ 1.473961] of_iommu_configure+0x270/0x2b8
[ 1.474069] of_dma_configure_id+0xc0/0x2f8
[ 1.474180] pci_dma_configure+0x5c/0x110
[ 1.474285] really_probe+0x7c/0x3a0
[ 1.474383] __driver_probe_device+0x84/0x160
[ 1.474488] driver_probe_device+0x44/0x130
[ 1.474597] __driver_attach+0xcc/0x208
[ 1.474700] bus_for_each_dev+0x84/0x100
[ 1.474803] driver_attach+0x2c/0x40
[ 1.474900] bus_add_driver+0x118/0x250
[ 1.474998] driver_register+0x70/0x138
[ 1.475096] __pci_register_driver+0x4c/0x60
[ 1.475198] igb_init_module+0x58/0x70
[ 1.475300] do_one_initcall+0x60/0x2f8
[ 1.475400] do_initcalls+0x114/0x158
[ 1.475500] kernel_init_freeable+0x18c/0x1e8
[ 1.475640] kernel_init+0x28/0x168
[ 1.475752] ret_from_fork+0x10/0x20
[ 1.476008] ---[ end trace 0000000000000000 ]---
Apart from the warning everything seems to still work, so a fix doesn't
seem too urgent and I can investigate during the merge window (I haven't
been following the probe rework).
Thanks,
Jean
