Re: [PATCH v3 1/3] iommu/amd: Use raw spinlock for interrupt remapping tables

[Magnus Kalland <magnus@dolphinics.com>]

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@amd.com/

> #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@dolphinics.com>