public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Niklas Cassel <cassel@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 14:39:49 -0600	[thread overview]
Message-ID: <20260210203949.GA47027@bhelgaas> (raw)
In-Reply-To: <aYuToukP3STMF6Tj@ryzen>

On Tue, Feb 10, 2026 at 09:22:58PM +0100, Niklas Cassel wrote:
> On Tue, Feb 10, 2026 at 01:32:05PM -0600, Bjorn Helgaas wrote:
> ...

> > Isn't there still a race between host updates of PCI_MSI_ADDRESS_*
> > and endpoint reads of those registers?  We can't prevent the host
> > from updating PCI_MSI_ADDRESS_* between dw_pcie_ep_map_addr() and
> > the writel(), so maybe it's impossible to prevent the theoretical
> > race there, and all we can really do is mitigate what we expect to
> > be a single change at boot time of the host?
> 
> Normally, the MSI target address is not changed during runtime.
> 
> The spec allows changing the MSI-X address/data pair when the
> corresponding vector is *masked*, and classifies the behavior as
> undefined if address/data pair gets changed while the vector is
> *unmasked*.
> 
> AFAICT, it does not mention anything for MSI, so I do not think it
> is allowed to be changed during runtime.
> 
> The only reason why it is changed here is because UEFI/BIOS will
> have one MSI target address, and then once Linux boots, it will use
> another MSI target address. (So it only changes once.)

Yes, hence "we expect a single change at boot time of the host" above.

> > Even for that single change, it looks like the host could update
> > PCI_MSI_ADDRESS_* simultaneously with dw_pcie_ep_raise_msi_irq(),
> > leading to mapping a half-updated msg_addr.  This part we *could*
> > prevent by re-reading PCI_MSI_ADDRESS_* to detect a partial
> > update.
> 
> The problem that commit 8719c64e76bf ("PCI: dwc: ep: Cache MSI
> outbound iATU mapping") fixes is that the DWC controller does not
> handle when the outbound iATU is re-programmed when there are
> ongoing outbound transactions.

The scenario I'm asking about is the following, where the single
change of MSI target as the host boots is concurrent with
dw_pcie_ep_raise_msi_irq()::

  - host writes PCI_MSI_ADDRESS_LO

  - dw_pcie_ep_raise_msi_irq() reads PCI_MSI_ADDRESS_LO and
    PCI_MSI_ADDRESS_HI

  - dw_pcie_ep_raise_msi_irq() maps msg_addr built from an old
    PCI_MSI_ADDRESS_HI and a new PCI_MSI_ADDRESS_LO

  - host writes PCI_MSI_ADDRESS_HI

This could be mitigated by re-reading PCI_MSI_ADDRESS_* to detect the
tearing.

  parent reply	other threads:[~2026-02-10 20:39 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
2026-02-10 20:39     ` Bjorn Helgaas [this message]
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=20260210203949.GA47027@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=den@valinux.co.jp \
    --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