All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: "Christoph Hellwig" <hch@lst.de>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Madhavan Srinivasan" <maddy@linux.ibm.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Marco Elver" <elver@google.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, iommu@lists.linux.dev,
	virtualization@lists.linux.dev, kasan-dev@googlegroups.com,
	linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org,
	"Jason Gunthorpe" <jgg@ziepe.ca>
Subject: Re: [PATCH 0/8] dma-mapping: migrate to physical address-based API
Date: Fri, 27 Jun 2025 20:02:13 +0300	[thread overview]
Message-ID: <20250627170213.GL17401@unreal> (raw)
In-Reply-To: <35df6f2a-0010-41fe-b490-f52693fe4778@samsung.com>

On Fri, Jun 27, 2025 at 03:44:10PM +0200, Marek Szyprowski wrote:
> On 25.06.2025 15:18, Leon Romanovsky wrote:
> > This series refactors the DMA mapping to use physical addresses
> > as the primary interface instead of page+offset parameters. This
> > change aligns the DMA API with the underlying hardware reality where
> > DMA operations work with physical addresses, not page structures.
> >
> > The series consists of 8 patches that progressively convert the DMA
> > mapping infrastructure from page-based to physical address-based APIs:
> >
> > The series maintains backward compatibility by keeping the old
> > page-based API as wrapper functions around the new physical
> > address-based implementations.
> 
> Thanks for this rework! I assume that the next step is to add map_phys 
> callback also to the dma_map_ops and teach various dma-mapping providers 
> to use it to avoid more phys-to-page-to-phys conversions.

Probably Christoph will say yes, however I personally don't see any
benefit in this. Maybe I wrong here, but all existing .map_page()
implementation platforms don't support p2p anyway. They won't benefit
from this such conversion.

> 
> I only wonder if this newly introduced dma_map_phys()/dma_unmap_phys() 
> API is also suitable for the recently discussed PCI P2P DMA? While 
> adding a new API maybe we should take this into account?

First, immediate user (not related to p2p) is blk layer:
https://lore.kernel.org/linux-nvme/bcdcb5eb-17ed-412f-bf5c-303079798fe2@nvidia.com/T/#m7e715697d4b2e3997622a3400243477c75cab406

+static bool blk_dma_map_direct(struct request *req, struct device *dma_dev,
+		struct blk_dma_iter *iter, struct phys_vec *vec)
+{
+	iter->addr = dma_map_page(dma_dev, phys_to_page(vec->paddr),
+			offset_in_page(vec->paddr), vec->len, rq_dma_dir(req));
+	if (dma_mapping_error(dma_dev, iter->addr)) {
+		iter->status = BLK_STS_RESOURCE;
+		return false;
+	}
+	iter->len = vec->len;
+	return true;
+}

Block layer started to store phys addresses instead of struct pages and
this phys_to_page() conversion in data-path will be avoided.

> My main concern is the lack of the source phys addr passed to the dma_unmap_phys() 
> function and I'm aware that this might complicate a bit code conversion 
> from old dma_map/unmap_page() API.
> 
> Best regards
> -- 
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
> 
> 

  reply	other threads:[~2025-06-27 17:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20250625131920eucas1p271b196cde042bd39ac08fb12beff5baf@eucas1p2.samsung.com>
2025-06-25 13:18 ` [PATCH 0/8] dma-mapping: migrate to physical address-based API Leon Romanovsky
2025-06-25 13:18   ` [PATCH 1/8] dma-debug: refactor to use physical addresses for page mapping Leon Romanovsky
2025-06-25 13:18   ` [PATCH 2/8] dma-mapping: rename trace_dma_*map_page to trace_dma_*map_phys Leon Romanovsky
2025-06-25 13:19   ` [PATCH 3/8] iommu/dma: rename iommu_dma_*map_page to iommu_dma_*map_phys Leon Romanovsky
2025-06-25 13:19   ` [PATCH 4/8] dma-mapping: convert dma_direct_*map_page to be phys_addr_t based Leon Romanovsky
2025-06-25 13:19   ` [PATCH 5/8] kmsan: convert kmsan_handle_dma to use physical addresses Leon Romanovsky
2025-06-26 17:43     ` Alexander Potapenko
2025-06-26 18:45       ` Leon Romanovsky
2025-06-27 16:28         ` Alexander Potapenko
2025-06-25 13:19   ` [PATCH 6/8] dma-mapping: fail early if physical address is mapped through platform callback Leon Romanovsky
2025-07-25 20:04     ` Robin Murphy
2025-07-27  6:30       ` Leon Romanovsky
2025-06-25 13:19   ` [PATCH 7/8] dma-mapping: export new dma_*map_phys() interface Leon Romanovsky
2025-06-25 13:19   ` [PATCH 8/8] mm/hmm: migrate to physical address-based DMA mapping API Leon Romanovsky
2025-07-15 13:24     ` Will Deacon
2025-07-15 13:58       ` Leon Romanovsky
2025-06-27 13:44   ` [PATCH 0/8] dma-mapping: migrate to physical address-based API Marek Szyprowski
2025-06-27 17:02     ` Leon Romanovsky [this message]
2025-06-30 13:38       ` Christoph Hellwig
2025-07-08 10:27         ` Marek Szyprowski
2025-07-08 11:00           ` Leon Romanovsky
2025-07-08 11:45             ` Marek Szyprowski
2025-07-08 12:06               ` Leon Romanovsky
2025-07-08 12:56                 ` Marek Szyprowski
2025-07-08 15:57                   ` Marek Szyprowski
2025-07-30 11:11           ` Robin Murphy
2025-07-30 13:40             ` Leon Romanovsky
2025-07-30 14:28               ` Jason Gunthorpe
2025-07-31  6:01                 ` Leon Romanovsky
2025-07-30 16:32             ` Marek Szyprowski
2025-07-31 17:37             ` Matthew Wilcox
2025-08-03 15:59               ` Jason Gunthorpe
2025-08-04  3:37                 ` Matthew Wilcox
2025-08-05 15:36                   ` Jason Gunthorpe
2025-07-06  6:00       ` Leon Romanovsky
2025-07-25 20:05   ` Robin Murphy
2025-07-29 14:03     ` Jason Gunthorpe

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=20250627170213.GL17401@unreal \
    --to=leon@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=corbet@lwn.net \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=eperezma@redhat.com \
    --cc=glider@google.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux.dev \
    --cc=jasowang@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maddy@linux.ibm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=mst@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=virtualization@lists.linux.dev \
    --cc=will@kernel.org \
    --cc=xuanzhuo@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.