public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Jingoo Han" <jingoohan1@gmail.com>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Koichiro Den" <den@valinux.co.jp>,
	"Shinichiro Kawasaki" <shinichiro.kawasaki@wdc.com>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: dwc: ep: Fix regression in dw_pcie_ep_raise_msi_irq()
Date: Tue, 10 Feb 2026 21:33:56 +0100	[thread overview]
Message-ID: <aYuWNOwXO54oYCWD@ryzen> (raw)
In-Reply-To: <aYuToukP3STMF6Tj@ryzen>

On Tue, Feb 10, 2026 at 09:22:58PM +0100, Niklas Cassel wrote:
> What commit 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping")
> did was to map it once on startup, that way we don't re-program the outbound
> iATU on every pci_epc_raise_irq() call. Before this commit, every
> pci_epc_raise_irq() call could potentially cause ongoing outbound transactions
> to be sent untranslated. Often the transactions that were sent untranslated
> did not appear to be the MSI writel() itself, but other transactions performed
> by the eDMA.

I guess it could have been the MSI writel() too.

Perhaps another fix could have been to just do a readl() after the writel(),
before the unmap().

If that is preferred, should be simple to test, since the bug is very easy
to reproduce, just run nvmet-pci-epf and do some transfers with a high queue
depth and see the IOMMU errors on the host.

I do like the solution that caches the MSI address though, as that avoids
the extra latency of a map() + unmap() for every pci_epc_raise_irq() call.


Kind regards,
Niklas

  reply	other threads:[~2026-02-10 20:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-10 18:12 [PATCH] PCI: dwc: ep: Fix regression in dw_pcie_ep_raise_msi_irq() Niklas Cassel
2026-02-10 19:32 ` Bjorn Helgaas
2026-02-10 20:22   ` Niklas Cassel
2026-02-10 20:33     ` Niklas Cassel [this message]
2026-02-10 20:39     ` Bjorn Helgaas
2026-02-11  8:52       ` Niklas Cassel
2026-02-11 18:08         ` Bjorn Helgaas
2026-02-25 14:59     ` Manivannan Sadhasivam
2026-02-11 16:44 ` Koichiro Den
2026-02-12  9:42 ` Shinichiro Kawasaki
2026-02-25 15:01 ` Manivannan Sadhasivam
2026-02-25 15:51   ` Niklas Cassel
2026-02-25 16:30     ` Manivannan Sadhasivam
2026-02-25 20:05 ` Bjorn Helgaas
2026-02-25 21:56   ` Niklas Cassel

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=aYuWNOwXO54oYCWD@ryzen \
    --to=cassel@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=den@valinux.co.jp \
    --cc=helgaas@kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=robh@kernel.org \
    --cc=shinichiro.kawasaki@wdc.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