public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Koichiro Den <den@valinux.co.jp>,
	Robin Murphy <robin.murphy@arm.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>
Cc: "Frank Li" <Frank.li@nxp.com>,
	"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>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Jon Mason" <jdmason@kudzu.us>,
	"Dave Jiang" <dave.jiang@intel.com>,
	"Allen Hubbe" <allenbh@gmail.com>,
	"Bhanu Seshu Kumar Valluri" <bhanuseshukumar@gmail.com>,
	"Marco Crivellari" <marco.crivellari@suse.com>,
	"Shin'ichiro Kawasaki" <shinichiro.kawasaki@wdc.com>,
	"Manikanta Maddireddy" <mmaddireddy@nvidia.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	ntb@lists.linux.dev, iommu@lists.linux.dev
Subject: Re: [PATCH v10 7/7] PCI: endpoint: pci-ep-msi: Add embedded doorbell fallback
Date: Thu, 26 Mar 2026 11:25:04 +0100	[thread overview]
Message-ID: <acUJgChL1hypb6ei@ryzen> (raw)
In-Reply-To: <acUDdigoIj_uusgI@ryzen>

On Thu, Mar 26, 2026 at 10:59:26AM +0100, Niklas Cassel wrote:
> On Thu, Mar 26, 2026 at 05:49:13PM +0900, Koichiro Den wrote:
> > > 
> > > The transaction is a write from
> > > PCIe bus -> PCIe controller iATU -> internal bus -> IOMMU -> PCIe controller
> > > (the same controller as initiated the transaction).
> > 
> > Yes, I think we're on the same page about this path itself.
> > 
> > On my R-Car S4 setup, changing this to DMA_TO_DEVICE consistently triggers an
> > IOMMU fault, so at least on this platform the local path used for the doorbell
> > mapping is IOMMU-visible. That is the case this dma_map_resource() is intended
> > to cover.
> > 
> > For that path, my understanding is that the doorbell access ends up as a local
> > write on the EP side, so it needs write permission, hence DMA_FROM_DEVICE.
> > 
> > > Would be interesting why this is not working like normal (when using buffers):
> > > "For Networking drivers, it’s a rather simple affair.
> > > For transmit packets, map/unmap them with the DMA_TO_DEVICE direction specifier.
> > > For receive packets, just the opposite, map/unmap them with the DMA_FROM_DEVICE
> > > direction specifier."
> > 
> > I think the closer analogy is RX: the data comes from outside, but the device
> > writes to the target, so it needs write permission.
> 
> I think it is from the PoV from the IOMMU, is the transaction a Read by a device
> or a Write by a device?
> 
> For a NIC driver:
> For a RX packet, the data is coming from the device to the memory.
> device is doing a transaction to memory.
> For a TX packet, the data is going from the memory to the device.
> 
> In our case, the data is coming from the device, to a device.
> 
> Almost like a P2P DMA, but in our case, both devices are the same, so
> using the P2P DMA API like pci_p2pdma_add_resource() seems unnecessary.
> 
> So should it be DMA_BIDIRECTIONAL ? :)
> 
> I understand that for the R-Car S4 Spider IOMMU, it is sufficient to map
> it as DMA_FROM_DEVICE. I just want to be sure that on some other IOMMU,
> they might consider it sufficient to map this as DMA_TO_DEVICE (because
> it is also a transaction going to a device).
> 
> I just want to make sure that the code works on more than one IOMMU.
> 
> Perhaps some IOMMU experts could help chime in.
> 
> 
> Note that I am happy to merge the code as is, as it obviously works on the
> only platform that this has been tested on (R-Car S4 Spider), and if other
> platform tries to run this test case, if their IOMMU works differently, it
> will scream and they will report it to the list. So all good.
> 
> I'm mostly want to know how the DMA-API is supposed to be used in this
> specific scenario (device doing a write transaction to the same device).

I guess if a device will be reading or writing from this IOVA that is
created by IOMMU by the dma_map() call...

The device will only be writing to this IOVA.
The device will never be reading from the IOVA (since the physical address
is a register in the device itself, we will never supply this IOVA for the
device to read from).

DMA_FROM_DEVICE seems correct in all cases. DMA_BIDIRECTIONAL seems wrong
since the device will never read from this IOVA. Sorry for the noise.


Kind regards,
Niklas

  reply	other threads:[~2026-03-26 10:25 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-02  7:14 [PATCH v10 0/7] PCI: endpoint: pci-ep-msi: Add embedded doorbell fallback Koichiro Den
2026-03-02  7:14 ` [PATCH v10 1/7] PCI: endpoint: Add auxiliary resource query API Koichiro Den
2026-03-21 14:17   ` Manivannan Sadhasivam
2026-03-23  1:34     ` Koichiro Den
2026-03-02  7:14 ` [PATCH v10 2/7] PCI: dwc: Record integrated eDMA register window Koichiro Den
2026-03-21 14:21   ` Manivannan Sadhasivam
2026-03-23  1:46     ` Koichiro Den
2026-03-24  8:06       ` Koichiro Den
2026-03-02  7:14 ` [PATCH v10 3/7] PCI: dwc: ep: Expose integrated eDMA resources via EPC aux-resource API Koichiro Den
2026-03-23 18:36   ` Frank Li
2026-03-24  8:45     ` Koichiro Den
2026-03-02  7:14 ` [PATCH v10 4/7] PCI: endpoint: pci-ep-msi: Refactor doorbell allocation for new backends Koichiro Den
2026-03-02  7:14 ` [PATCH v10 5/7] PCI: endpoint: pci-epf-vntb: Reuse pre-exposed doorbells and IRQ flags Koichiro Den
2026-03-23 18:39   ` Frank Li
2026-03-02  7:14 ` [PATCH v10 6/7] PCI: endpoint: pci-epf-test: Reuse pre-exposed doorbell targets Koichiro Den
2026-03-23 18:41   ` Frank Li
2026-03-02  7:14 ` [PATCH v10 7/7] PCI: endpoint: pci-ep-msi: Add embedded doorbell fallback Koichiro Den
2026-03-02 10:07   ` Niklas Cassel
2026-03-23 18:48   ` Frank Li
2026-03-24  1:40     ` Koichiro Den
2026-03-25  7:06       ` Niklas Cassel
2026-03-25  8:43         ` Koichiro Den
2026-03-25 16:56           ` Niklas Cassel
2026-03-26  8:49             ` Koichiro Den
2026-03-26  9:59               ` Niklas Cassel
2026-03-26 10:25                 ` Niklas Cassel [this message]
2026-03-26 12:12                   ` Robin Murphy
2026-03-26 14:38                     ` Koichiro Den

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=acUJgChL1hypb6ei@ryzen \
    --to=cassel@kernel.org \
    --cc=Frank.li@nxp.com \
    --cc=allenbh@gmail.com \
    --cc=bhanuseshukumar@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=dave.jiang@intel.com \
    --cc=den@valinux.co.jp \
    --cc=iommu@lists.linux.dev \
    --cc=jdmason@kudzu.us \
    --cc=jingoohan1@gmail.com \
    --cc=joro@8bytes.org \
    --cc=kishon@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mani@kernel.org \
    --cc=marco.crivellari@suse.com \
    --cc=mmaddireddy@nvidia.com \
    --cc=ntb@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=will@kernel.org \
    /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