Re: [PATCH v3 1/3] iommu/amd: Use raw spinlock for interrupt remapping tables
From: Magnus Kalland
Date: Tue Mar 31 2026 - 09:10:33 EST
Hi again Vasant.
Not sure if I understand correctly, but I'll try to answer based on how I
read it.
On Mon, Mar 30, 2026 at 08:53:48PM +0530, Vasant Hegde wrote:
> I spent sometime going through entire flow. I think we can re-arrange code so
> that we can avoid this lock change.
>
> #1 ) alloc_irq_table()
> Remove iommu_flush_dte() from set_remap_table_entry /
> set_remap_table_entry_alias
> Once table is updated, at the end of this function we can have a logic to
> flush/completion wait.
The reason we change iommu_table_lock is not just because of the nested raw
spinlocking (holding iommu_table_lock under iommu_lock): it's also because of
the locking context from __setup_irq. Again, see this:
https://lore.kernel.org/linux-iommu/26cfa307-6c33-41f9-a7a0-fbf202b38a00@xxxxxxx/
> #2) iommu_flush_irt_and_complete()
> This needs to be reworked to match device_flush_dte()
>
> Makes sense? Did I miss anything?
Same here. We cannot rework based on the logic in device_flush_dte using
pci_for_each_dma_alias, so we rely solely on alias_table. But we notice that
device_flush_dte is called without holding iommu_table_lock, so if we can do
the same, then changing the lock type won't be necessary.
Please let me know if there is a misunderstanding somewhere along the way.
Thanks,
Magnus
Signed-off-by: Magnus Kalland <magnus@xxxxxxxxxxxxxx>