From: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
To: Magnus Kalland <magnus@dolphinics.com>, <vasant.hegde@amd.com>,
<suravee.suthikulpanit@amd.com>, <joro@8bytes.org>,
<iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org>
Cc: <dhsrivas@amd.com>, "Lars B . Kristiansen" <larsk@dolphinics.com>,
"Jonas Markussen" <jonas@dolphinics.com>,
"Tore H . Larsen" <torel@simula.no>
Subject: Re: [PATCH v3 0/3] iommu/amd: Invalidate IRT cache for DMA aliases
Date: Fri, 13 Mar 2026 13:16:56 +0530 [thread overview]
Message-ID: <5de2362c-61e2-4287-8735-8fcbc8a1ab09@amd.com> (raw)
In-Reply-To: <20260306092230.132183-1-magnus@dolphinics.com>
Hi
On 3/6/2026 2:52 PM, Magnus Kalland wrote:
> DMA aliasing causes interrupt remapping table entries (IRTEs) to be shared
> between multiple device IDs. See commit 3c124435e8dd
> ("iommu/amd: Support multiple PCI DMA aliases in IRQ Remapping") for more
> information on this. However, the AMD IOMMU driver currently invalidates
> IRTE cache entries on a per-device basis whenever an IRTE is updated, not
> for each alias.
>
> This approach leaves stale IRTE cache entries when an IRTE is cached under
> one DMA alias but later updated and invalidated through a different alias.
> In such cases, the original device ID is never invalidated, since it is
> programmed via aliasing.
>
> This incoherency bug has been observed when IRTEs are cached for one
> Non-Transparent Bridge (NTB) DMA alias, later updated via another.
>
> Fix this by invalidating the interrupt remapping table cache for all DMA
> aliases when updating an IRTE.
>
> Changes since v2:
> - Look for aliases with pci_seg->alias_table instead of
> pci_for_each_dma_alias since we can't get the pdev (lockdep).
> Track the aliases in set_remap_table_entry_alias. Invalidate IRT cache
> for each BDF sharing alias with the given devid in
> iommu_flush_irt_and_complete.
> - Make iommu_table_lock a raw spinlock to use it when invalidating
> IRT caches.
> - Rebased and applied cleanly on the IOMMU maintainers tree
>
> Resending for visibility.
I tested the patch with lockdep (CONFIG_PROVE_LOCKING=y) enabled and
observed the following lockdep warnings in the kernel logs.
[ 13.224217] kernel: =============================
[ 13.224217] kernel: [ BUG: Invalid wait context ]
[ 13.224217] kernel: 7.0.0-rc3-eee9d444276c-1773350434439 #1 Not tainted
[ 13.224217] kernel: -----------------------------
[ 13.224217] kernel: kworker/0:1/11 is trying to lock:
[ 13.224217] kernel: ff364c9da9e416b8
(&dev_data->dte_lock){....}-{3:3}, at: set_dte_irq_entry+0x84/0x150
[ 13.224217] kernel: other info that might help us debug this:
[ 13.224217] kernel: context-{5:5}
[ 13.224217] kernel: 5 locks held by kworker/0:1/11:
[ 13.224217] kernel: #0: ff364bde58164158
((wq_completion)sync_wq){+.+.}-{0:0}, at: process_one_work+0x4c0/0x730
[ 13.224217] kernel: #1: ff8437db001efe48
((work_completion)(&arg.work)){+.+.}-{0:0}, at: process_one_work+0x1ee/0x730
[ 13.224217] kernel: #2: ff364bde63dabaa0 (&md->mutex){+.+.}-{4:4},
at: __pci_enable_msi_range+0x228/0x360
[ 13.224217] kernel: #3: ff364bde4109bca0
(&domain->mutex){+.+.}-{4:4}, at: __irq_domain_alloc_irqs+0x3b/0xa0
[ 13.224217] kernel: #4: ffffffff886590f8
(iommu_table_lock){....}-{2:2}, at: alloc_irq_table+0x190/0x2c0
[ 13.224217] kernel: stack backtrace:
[ 13.224217] kernel: CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not
tainted 7.0.0-rc3-eee9d444276c-1773350434439 #1 PREEMPT(lazy)
[ 13.224217] kernel: Hardware name: AMD Corporation
Titanite_4G/Titanite_4G, BIOS RTI100FD_1 03/25/2025
[ 13.224217] kernel: Workqueue: sync_wq local_pci_probe_callback
[ 13.224217] kernel: Call Trace:
[ 13.224217] kernel: <TASK>
[ 13.224217] kernel: dump_stack_lvl+0x78/0xe0
[ 13.224217] kernel: __lock_acquire+0x836/0xbe0
[ 13.224217] kernel: lock_acquire+0xc7/0x300
[ 13.224217] kernel: ? set_dte_irq_entry+0x84/0x150
[ 13.224217] kernel: ? lock_acquire+0xc7/0x300
[ 13.224217] kernel: ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.224217] kernel: _raw_spin_lock+0x34/0x80
[ 13.224217] kernel: ? set_dte_irq_entry+0x84/0x150
[ 13.224217] kernel: set_dte_irq_entry+0x84/0x150
[ 13.224217] kernel: set_remap_table_entry_alias+0x64/0x90
[ 13.224217] kernel: ? __pfx_set_remap_table_entry_alias+0x10/0x10
[ 13.224217] kernel: pci_for_each_dma_alias+0x3f/0x150
[ 13.224217] kernel: alloc_irq_table+0x1f9/0x2c0
[ 13.224217] kernel: alloc_irq_index+0x2c/0x170
[ 13.224217] kernel: ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.224217] kernel: irq_remapping_alloc+0x1b6/0x520
[ 13.224217] kernel: msi_domain_alloc+0x71/0x140
[ 13.224217] kernel: irq_domain_alloc_irqs_locked+0xd2/0x370
[ 13.224217] kernel: __irq_domain_alloc_irqs+0x56/0xa0
[ 13.224217] kernel: __msi_domain_alloc_irqs+0x1f7/0x430
[ 13.224217] kernel: msi_domain_alloc_irqs_all_locked+0x5a/0xa0
[ 13.224217] kernel: __msi_capability_init+0x152/0x240
[ 13.224217] kernel: __pci_enable_msi_range+0x234/0x360
[ 13.224217] kernel: pci_alloc_irq_vectors_affinity+0xc5/0x110
[ 13.224217] kernel: pcie_port_enable_irq_vec+0x3e/0x220
[ 13.224217] kernel: ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.224217] kernel: ? __pci_set_master+0x55/0xe0
[ 13.224217] kernel: pcie_portdrv_probe+0xdf/0x2f0
[ 13.224217] kernel: ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.224217] kernel: local_pci_probe+0x41/0x90
[ 13.224217] kernel: local_pci_probe_callback+0x16/0x20
[ 13.224217] kernel: process_one_work+0x22f/0x730
[ 13.224217] kernel: worker_thread+0x1d3/0x3a0
[ 13.224217] kernel: ? __pfx_worker_thread+0x10/0x10
[ 13.224217] kernel: kthread+0xe6/0x120
[ 13.224217] kernel: ? __pfx_kthread+0x10/0x10
[ 13.224217] kernel: ret_from_fork+0x2cb/0x340
[ 13.224217] kernel: ? __pfx_kthread+0x10/0x10
[ 13.224217] kernel: ret_from_fork_asm+0x1a/0x30
[ 13.224217] kernel: </TASK>
Thanks
Dheeraj
>
> Link: https://lore.kernel.org/linux-iommu/26cfa307-6c33-41f9-a7a0-fbf202b38a00@amd.com/
> Co-developed-by: Lars B. Kristiansen <larsk@dolphinics.com>
> Signed-off-by: Lars B. Kristiansen <larsk@dolphinics.com>
> Co-developed-by: Jonas Markussen <jonas@dolphinics.com>
> Signed-off-by: Jonas Markussen <jonas@dolphinics.com>
> Co-developed-by: Tore H. Larsen <torel@simula.no>
> Signed-off-by: Tore H. Larsen <torel@simula.no>
> Signed-off-by: Magnus Kalland <magnus@dolphinics.com>
>
> Magnus Kalland (3):
> iommu/amd: Use raw spinlock for interrupt remapping tables
> iommu/amd: Track PCIe DMA aliases in set_remap_table_entry_alias
> iommu/amd: Invalidate IRT cache for DMA aliases
>
> drivers/iommu/amd/iommu.c | 52 +++++++++++++++++++++++++++++++++------
> 1 file changed, 45 insertions(+), 7 deletions(-)
>
next prev parent reply other threads:[~2026-03-13 7:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 9:22 Magnus Kalland
2026-03-06 9:22 ` [PATCH v3 1/3] iommu/amd: Use raw spinlock for interrupt remapping tables Magnus Kalland
2026-03-06 9:22 ` [PATCH v3 2/3] iommu/amd: Track PCIe DMA aliases in set_remap_table_entry_alias Magnus Kalland
2026-03-06 9:22 ` [PATCH v3 3/3] iommu/amd: Invalidate IRT cache for DMA aliases Magnus Kalland
2026-03-13 7:46 ` Dheeraj Kumar Srivastava [this message]
2026-03-17 10:58 ` [PATCH v3 0/3] " Magnus Kalland
-- strict thread matches above, loose matches on Subject: below --
2026-02-25 20:23 Magnus Kalland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5de2362c-61e2-4287-8735-8fcbc8a1ab09@amd.com \
--to=dheerajkumar.srivastava@amd.com \
--cc=dhsrivas@amd.com \
--cc=iommu@lists.linux.dev \
--cc=jonas@dolphinics.com \
--cc=joro@8bytes.org \
--cc=larsk@dolphinics.com \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus@dolphinics.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=torel@simula.no \
--cc=vasant.hegde@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®