dma-mapping: migrate to physical address-based API

From: Leon Romanovsky <[email protected]>

Introduce new DMA mapping functions dma_map_phys() and dma_unmap_phys() that operate directly on physical addresses instead of page+offset parameters. This provides a more efficient interface for drivers that already have physical addresses available.

The new functions are implemented as the primary mapping layer, with the existing dma_map_page_attrs()/dma_map_resource() and dma_unmap_page_attrs()/dma_unmap_resource() functions converted to simple wrappers around the phys-based implementations.

In case dma_map_page_attrs(), the struct page is converted to physical address with help of page_to_phys() function and dma_map_resource() provides physical address as is together with addition of DMA_ATTR_MMIO attribute.

The old page-based API is preserved in mapping.c to ensure that existing code won't be affected by changing EXPORT_SYMBOL to EXPORT_SYMBOL_GPL variant for dma_*map_phys().

From: Leon Romanovsky <[email protected]>

Make sure that CPU is not synced and IOMMU is configured to take MMIO path by providing newly introduced DMA_ATTR_MMIO attribute.

block/blk-mq-dma.c static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec) · line 91

Quoted 7 lines · Leon Romanovsky

static bool blk_dma_map_direct(struct request *req, struct device *dma_dev,

block/blk-mq-dma.c +2 -2

 		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));
+	iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len,
+			rq_dma_dir(req), 0);

Looks good.

Reviewed-by Keith Busch <[email protected]>

Just a random thought when I had to double back to check what the "0"
means: many dma_ api's have a default macro without an "attrs" argument, then an _attrs() version for when you need it. Not sure if you want to strictly follow that pattern, but merely a suggestion.

From: Leon Romanovsky <[email protected]>

Block layer maps MMIO memory through dma_map_phys() interface with help of DMA_ATTR_MMIO attribute. There is a need to unmap that memory with the appropriate unmap function, something which wasn't possible before adding new REQ attribute to block layer in previous patch.

Changelog:
v4:
* Fixed kbuild error with mismatch in kmsan function declaration due to rebase error.
v3: https://lore.kernel.org/all/[email protected]
* Fixed typo in "cacheable" word
* Simplified kmsan patch a lot to be simple argument refactoring
v2: https://lore.kernel.org/all/[email protected]
* Used commit messages and cover letter from Jason
* Moved setting IOMMU_MMIO flag to dma_info_to_prot function
* Micro-optimized the code
* Rebased code on v6.17-rc1
v1: https://lore.kernel.org/all/[email protected]
* Added new DMA_ATTR_MMIO attribute to indicate PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path.
* Rewrote dma_map_* functions to use thus new attribute
v0: https://lore.kernel.org/all/[email protected]/
------------------------------------------------------------------------

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 maintains export symbol backward compatibility by keeping the old page-based API as wrapper functions around the new physical address-based implementations.

This series refactors the DMA mapping API to provide a phys_addr_t based, and struct-page free, external API that can handle all the mapping cases we want in modern systems:

- struct page based cachable DRAM
- struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cachable MMIO
- struct page-less PCI peer to peer non-cachable MMIO
- struct page-less "resource" MMIO

Overall this gets much closer to Matthew's long term wish for struct-pageless IO to cachable DRAM. The remaining primary work would be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on phys_addr_t without a struct page.

The general design is to remove struct page usage entirely from the DMA API inner layers. For flows that need to have a KVA for the physical address they can use kmap_local_pfn() or phys_to_virt(). This isolates the struct page requirements to MM code only. Long term all removals of struct page usage are supporting Matthew's memdesc project which seeks to substantially transform how struct page works.

Instead make the DMA API internals work on phys_addr_t. Internally there are still dedicated 'page' and 'resource' flows, except they are now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both flows use the same phys_addr_t.

When DMA_ATTR_MMIO is specified things work similar to the existing 'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(), pfn_valid(), etc are never called on the phys_addr_t. This requires rejecting any configuration that would need swiotlb. CPU cache flushing is not required, and avoided, as ATTR_MMIO also indicates the address have no cachable mappings. This effectively removes any DMA API side requirement to have struct page when DMA_ATTR_MMIO is used.

In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow, except on the common path of no cache flush, no swiotlb it never touches a struct page. When cache flushing or swiotlb copying kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU usage. This was already the case on the unmap side, now the map side is symmetric.

Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA path must also set it. This corrects some existing bugs where iommu mappings for P2P MMIO were improperly marked IOMMU_CACHE.

Since ATTR_MMIO is made to work with all the existing DMA map entry points, particularly dma_iova_link(), this finally allows a way to use the new DMA API to map PCI P2P MMIO without creating struct page. The VFIO DMABUF series demonstrates how this works. This is intended to replace the incorrect driver use of dma_map_resource() on PCI BAR addresses.

This series does the core code and modern flows. A followup series will give the same treatment to the legacy dma_ops implementation.

Thanks

Leon Romanovsky (16):
dma-mapping: introduce new DMA attribute to indicate MMIO memory iommu/dma: implement DMA_ATTR_MMIO for dma_iova_link().
dma-debug: refactor to use physical addresses for page mapping
dma-mapping: rename trace_dma_*map_page to trace_dma_*map_phys iommu/dma: rename iommu_dma_*map_page to iommu_dma_*map_phys iommu/dma: extend iommu_dma_*map_phys API to handle MMIO memory
dma-mapping: convert dma_direct_*map_page to be phys_addr_t based
kmsan: convert kmsan_handle_dma to use physical addresses
dma-mapping: handle MMIO flow in dma_map|unmap_page
xen: swiotlb: Open code map_resource callback
dma-mapping: export new dma_*map_phys() interface mm/hmm: migrate to physical address-based DMA mapping API mm/hmm: properly take MMIO path
block-dma: migrate to dma_map_phys instead of map_page
block-dma: properly take MMIO path
nvme-pci: unmap MMIO pages with appropriate interface

 Documentation/core-api/dma-api.rst        |   4 +-
 Documentation/core-api/dma-attributes.rst |  18 ++++
 arch/powerpc/kernel/dma-iommu.c           |   4 +-
 block/blk-mq-dma.c                        |  15 ++-
 drivers/iommu/dma-iommu.c                 |  61 +++++------
 drivers/nvme/host/pci.c                   |  18 +++-
 drivers/virtio/virtio_ring.c              |   4 +-
 drivers/xen/swiotlb-xen.c                 |  21 +++-
 include/linux/blk-mq-dma.h                |   6 +-
 include/linux/blk_types.h                 |   2 +
 include/linux/dma-direct.h                |   2 -
 include/linux/dma-map-ops.h               |   8 +-
 include/linux/dma-mapping.h               |  33 ++++++
 include/linux/iommu-dma.h                 |  11 +-
 include/linux/kmsan.h                     |   9 +-
 include/trace/events/dma.h                |   9 +-
 kernel/dma/debug.c                        |  71 ++++---------
 kernel/dma/debug.h                        |  37 ++-----
 kernel/dma/direct.c                       |  22 +---

 kernel/dma/direct.h                       |  52 ++++++----
 kernel/dma/mapping.c                      | 117 +++++++++++++---------
 kernel/dma/ops_helpers.c                  |   6 +-
 mm/hmm.c                                  |  19 ++--
 mm/kmsan/hooks.c                          |   5 +-
 rust/kernel/dma.rs                        |   3 +
 tools/virtio/linux/kmsan.h                |   2 +-
 26 files changed, 305 insertions(+), 254 deletions(-)

Signature · 2 lines

-- 
2.50.1

From: Leon Romanovsky <[email protected]>

This patch introduces the DMA_ATTR_MMIO attribute to mark DMA buffers that reside in memory-mapped I/O (MMIO) regions, such as device BARs exposed through the host bridge, which are accessible for peer-to-peer (P2P) DMA.

This attribute is especially useful for exporting device memory to other devices for DMA without CPU involvement, and avoids unnecessary or potentially detrimental CPU cache maintenance calls.

DMA_ATTR_MMIO is supposed to provide dma_map_resource() functionality without need to call to special function and perform branching by the callers.

Signed-off-by Leon Romanovsky <[email protected]>

---
 Documentation/core-api/dma-attributes.rst | 18 ++++++++++++++++++
 include/linux/dma-mapping.h               | 20 ++++++++++++++++++++
 include/trace/events/dma.h                |  3 ++-
 rust/kernel/dma.rs                        |  3 +++
 4 files changed, 43 insertions(+), 1 deletion(-)

(quoted diff) +5 -4

@@ -1218,19 +1219,24 @@ void debug_dma_map_page(struct device *dev, struct page *page, size_t offset,
 		return;
 
 	entry->dev       = dev;
-	entry->type      = dma_debug_single;
-	entry->paddr	 = page_to_phys(page) + offset;
+	entry->type      = dma_debug_phy;
+	entry->paddr	 = phys;
 	entry->dev_addr  = dma_addr;
 	entry->size      = size;
 	entry->direction = direction;
 	entry->map_err_type = MAP_ERR_NOT_CHECKED;
 
-	check_for_stack(dev, page, offset);
+	if (!(attrs & DMA_ATTR_MMIO)) {
+		struct page *page = phys_to_page(phys);
+		size_t offset = offset_in_page(page);
 
-	if (!PageHighMem(page)) {

From: Leon Romanovsky <[email protected]>

As a preparation for following map_page -> map_phys API conversion, let's rename trace_dma_*map_page() to be trace_dma_*map_phys().

Signed-off-by Leon Romanovsky <[email protected]>

---
 include/trace/events/dma.h | 4 ++--
 kernel/dma/mapping.c       | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

From: Leon Romanovsky <[email protected]>

Rename the IOMMU DMA mapping functions to better reflect their actual calling convention. The functions iommu_dma_map_page() and iommu_dma_unmap_page() are renamed to iommu_dma_map_phys() and iommu_dma_unmap_phys() respectively, as they already operate on physical addresses rather than page structures.

The calling convention changes from accepting (struct page *page, unsigned long offset) to (phys_addr_t phys), which eliminates the need for page-to-physical address conversion within the functions. This renaming prepares for the broader DMA API conversion from page-based to physical address-based mapping throughout the kernel.

All callers are updated to pass physical addresses directly, including dma_map_page_attrs(), scatterlist mapping functions, and DMA page allocation helpers. The change simplifies the code by removing the page_to_phys() + offset calculation that was previously done inside the IOMMU functions.

Signed-off-by Leon Romanovsky <[email protected]>

---
 drivers/iommu/dma-iommu.c | 14 ++++++--------
 include/linux/iommu-dma.h |  7 +++----
 kernel/dma/mapping.c      |  4 ++--
 kernel/dma/ops_helpers.c  |  6 +++---
 4 files changed, 14 insertions(+), 17 deletions(-)

From: Leon Romanovsky <[email protected]>

Combine iommu_dma_*map_phys with iommu_dma_*map_resource interfaces in order to allow single phys_addr_t flow.

In the following patches, the iommu_dma_map_resource() will be removed in favour of iommu_dma_map_phys(..., attrs | DMA_ATTR_MMIO) flow.

kernel/dma/direct.h +8 -4

+static inline dma_addr_t dma_direct_map_phys(struct device *dev,
+		phys_addr_t phys, size_t size, enum dma_data_direction dir,
+		unsigned long attrs)
 {
-	phys_addr_t phys = page_to_phys(page) + offset;
-	dma_addr_t dma_addr = phys_to_dma(dev, phys);
+	dma_addr_t dma_addr;
+	bool capable;
 
 	if (is_swiotlb_force_bounce(dev)) {
-		if (is_pci_p2pdma_page(page))
-			return DMA_MAPPING_ERROR;
+		if (attrs & DMA_ATTR_MMIO)
+			goto err_overflow;
+
 		return swiotlb_map(dev, phys, size, dir, attrs);
 	}

From: Leon Romanovsky <[email protected]>

Extend base DMA page API to handle MMIO flow and follow existing dma_map_resource() implementation to rely on dma_map_direct() only to take DMA direct path.

From: Leon Romanovsky <[email protected]>

General dma_direct_map_resource() is going to be removed in next patch, so simply open-code it in xen driver.

Reviewed-by Juergen Gross <[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

---
 drivers/xen/swiotlb-xen.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

include/linux/blk_types.h +1 -0

index 09b99d52fd36..283058bcb5b1 100644
@@ -387,6 +387,7 @@ enum req_flag_bits {
 	__REQ_FS_PRIVATE,	/* for file system (submitter) use */
 	__REQ_ATOMIC,		/* for atomic write operations */
 	__REQ_P2PDMA,		/* contains P2P DMA pages */
+	__REQ_MMIO,		/* contains MMIO memory */
 	/*
 	 * Command specific flags, keep last:
 	 */

The old page-based API is preserved in mapping.c to ensure that existing code won't be affected by changing EXPORT_SYMBOL to EXPORT_SYMBOL_GPL variant for dma_*map_phys().

Signed-off-by Leon Romanovsky <[email protected]>

---
 drivers/iommu/dma-iommu.c   | 14 --------
 include/linux/dma-direct.h  |  2 --
 include/linux/dma-mapping.h | 13 +++++++
 include/linux/iommu-dma.h   |  4 ---
 include/trace/events/dma.h  |  2 --
 kernel/dma/debug.c          | 43 -----------------------
 kernel/dma/debug.h          | 21 -----------
 kernel/dma/direct.c         | 16 ---------
 kernel/dma/mapping.c        | 69 ++++++++++++++++++++-----------------
 9 files changed, 50 insertions(+), 134 deletions(-)

Quoted 14 lines · Leon Romanovsky

include/linux/blk_types.h +1 -0

index 09b99d52fd36..283058bcb5b1 100644
@@ -387,6 +387,7 @@ enum req_flag_bits {
 	__REQ_FS_PRIVATE,	/* for file system (submitter) use */
 	__REQ_ATOMIC,		/* for atomic write operations */
 	__REQ_P2PDMA,		/* contains P2P DMA pages */
+	__REQ_MMIO,		/* contains MMIO memory */
 	/*
 	 * Command specific flags, keep last:
 	 */

@@ -420,6 +421,7 @@ enum req_flag_bits {
 #define REQ_FS_PRIVATE	(__force blk_opf_t)(1ULL << __REQ_FS_PRIVATE)

include/linux/blk_types.h enum req_flag_bits { · line 424

Quoted 3 lines

include/linux/blk_types.h +1 -0

 #define REQ_ATOMIC	(__force blk_opf_t)(1ULL << __REQ_ATOMIC)
 #define REQ_P2PDMA	(__force blk_opf_t)(1ULL << __REQ_P2PDMA)
+#define REQ_MMIO	(__force blk_opf_t)(1ULL << __REQ_MMIO)

Now that my integrity metadata DMA series is staged, I don't think we can use REQ flags like this because data and metadata may have different mapping types. I think we should add a flags field to the dma_iova_state instead.

Quoted 15 lines · Keith Busch

Quoted 14 lines · Leon Romanovsky

include/linux/blk_types.h +1 -0

index 09b99d52fd36..283058bcb5b1 100644
@@ -387,6 +387,7 @@ enum req_flag_bits {
 	__REQ_FS_PRIVATE,	/* for file system (submitter) use */
 	__REQ_ATOMIC,		/* for atomic write operations */
 	__REQ_P2PDMA,		/* contains P2P DMA pages */
+	__REQ_MMIO,		/* contains MMIO memory */
 	/*
 	 * Command specific flags, keep last:
 	 */

@@ -420,6 +421,7 @@ enum req_flag_bits {
 #define REQ_FS_PRIVATE	(__force blk_opf_t)(1ULL << __REQ_FS_PRIVATE)

Quoted 8 lines

include/linux/blk_types.h enum req_flag_bits { · line 424

Quoted 3 lines

include/linux/blk_types.h +1 -0

 #define REQ_ATOMIC	(__force blk_opf_t)(1ULL << __REQ_ATOMIC)
 #define REQ_P2PDMA	(__force blk_opf_t)(1ULL << __REQ_P2PDMA)
+#define REQ_MMIO	(__force blk_opf_t)(1ULL << __REQ_MMIO)

Now that my integrity metadata DMA series is staged, I don't think we can use REQ flags like this because data and metadata may have different mapping types. I think we should add a flags field to the dma_iova_state instead.

Before integrity metadata code was merged, the assumption was that request is only one type or p2p or host. Is it still holding now?

And we can't store in dma_iova_state() as HMM/RDMA code works in page-based granularity and one dma_iova_state() can mix different types.

Quoted 25 lines · Leon Romanovsky

Quoted 23 lines · Keith Busch

Quoted 13 lines · Leon Romanovsky

include/linux/blk_types.h +1 -0

index 09b99d52fd36..283058bcb5b1 100644
@@ -387,6 +387,7 @@ enum req_flag_bits {
 	__REQ_FS_PRIVATE,	/* for file system (submitter) use */
 	__REQ_ATOMIC,		/* for atomic write operations */
 	__REQ_P2PDMA,		/* contains P2P DMA pages */
+	__REQ_MMIO,		/* contains MMIO memory */
 	/*
 	 * Command specific flags, keep last:
 	 */

include/linux/blk_types.h enum req_flag_bits { · line 424

Quoted 4 lines

include/linux/blk_types.h +1 -0

@@ -420,6 +421,7 @@ enum req_flag_bits {
 #define REQ_FS_PRIVATE	(__force blk_opf_t)(1ULL << __REQ_FS_PRIVATE)
 #define REQ_ATOMIC	(__force blk_opf_t)(1ULL << __REQ_ATOMIC)
 #define REQ_P2PDMA	(__force blk_opf_t)(1ULL << __REQ_P2PDMA)
+#define REQ_MMIO	(__force blk_opf_t)(1ULL << __REQ_MMIO)

Now that my integrity metadata DMA series is staged, I don't think we can use REQ flags like this because data and metadata may have different mapping types. I think we should add a flags field to the dma_iova_state instead.

Quoted 2 lines

Before integrity metadata code was merged, the assumption was that request is only one type or p2p or host. Is it still holding now?

I don't think that was ever the case. Metadata is allocated independently of the data payload, usually by the kernel in bio_integrity_prep() just before dispatching the request. The bio may have a p2p data payload, but the integrity metadata is just a kmalloc buf in that path.

Quoted 6 lines · Keith Busch

I don't think that was ever the case. Metadata is allocated independently of the data payload, usually by the kernel in bio_integrity_prep() just before dispatching the request. The bio may have a p2p data payload, but the integrity metadata is just a kmalloc buf in that path.

Then you should do two dma mapping operations today, that is how the API was built. You shouldn't mix P2P and non P2P within a single operation right now..

Quoted 8 lines · Jason Gunthorpe

Quoted 6 lines · Keith Busch

I don't think that was ever the case. Metadata is allocated independently of the data payload, usually by the kernel in bio_integrity_prep() just before dispatching the request. The bio may have a p2p data payload, but the integrity metadata is just a kmalloc buf in that path.

Quoted 3 lines

Then you should do two dma mapping operations today, that is how the API was built. You shouldn't mix P2P and non P2P within a single operation right now..

Data and metadata are mapped as separate operations. They're just different parts of one blk-mq request.

Quoted 3 lines · Keith Busch

Data and metadata are mapped as separate operations. They're just different parts of one blk-mq request.

In that case the new bit leon proposes should only be used for the unmap of the data pages and the metadata unmap should always be unmapped as CPU?

In truth though, I hadn't tried p2p metadata before today, and it looks like bio_integrity_map_user() is missing the P2P extraction flags to make that work. Just added this patch below, now I can set p2p or host memory independently for data and integrity payloads:

Quoted 4 lines · Keith Busch

In truth though, I hadn't tried p2p metadata before today, and it looks like bio_integrity_map_user() is missing the P2P extraction flags to make that work. Just added this patch below, now I can set p2p or host memory independently for data and integrity payloads:

I think it is a bit more than that, you have to make sure all the meta data is the same, either all p2p or all cpu and then record this somehow so the DMA mapping knows what kind it is.

Once that is all done then the above should still be OK, the dma unmap of the data can follow Leon's new flag and the dma unmap of the integrity can follow however integrity kept track (in the bio_integrity_payload perhaps?) ??

This series does the core code and modern flows. A followup series will give the same treatment to the legacy dma_ops implementation.

Quoted 5 lines · Leon Romanovsky

From: Leon Romanovsky <[email protected]>

Extend base DMA page API to handle MMIO flow and follow existing dma_map_resource() implementation to rely on dma_map_direct() only to take DMA direct path.

I would reword this a little bit too

dma-mapping: implement DMA_ATTR_MMIO for dma_(un)map_page_attrs()

Make dma_map_page_attrs() and dma_map_page_attrs() respect DMA_ATTR_MMIO.

DMA_ATR_MMIO makes the functions behave the same as dma_(un)map_resource():
- No swiotlb is possible
- Legacy dma_ops arches use ops->map_resource()
- No kmsan
- No arch_dma_map_phys_direct()

The prior patches have made the internl funtions called here support DMA_ATTR_MMIO.

This is also preparation for turning dma_map_resource() into an inline calling dma_map_phys(DMA_ATTR_MMIO) to consolidate the flows.

kernel/dma/mapping.c dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, · line 171

Quoted 7 lines

kernel/dma/mapping.c +1 -1

@@ -166,14 +167,25 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
 		return DMA_MAPPING_ERROR;
 
 	if (dma_map_direct(dev, ops) ||
-	    arch_dma_map_phys_direct(dev, phys + size))
+	    (!is_mmio && arch_dma_map_phys_direct(dev, phys + size)))
 		addr = dma_direct_map_phys(dev, phys, size, dir, attrs);

PPC is the only user of arch_dma_map_phys_direct() and it looks like it should be called on MMIO memory. Seems like another inconsistency with map_resource. I'd leave it like the above though for this series.

kernel/dma/mapping.c dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page, · line 176

Quoted 6 lines

kernel/dma/mapping.c +3 -1

 	else if (use_dma_iommu(dev))
 		addr = iommu_dma_map_phys(dev, phys, size, dir, attrs);
-	else
+	else if (is_mmio) {
+		if (!ops->map_resource)
+			return DMA_MAPPING_ERROR;

Probably written like:

		if (ops->map_resource)
			addr = ops->map_resource(dev, phys, size, dir, attrs);
		else
			addr = DMA_MAPPING_ERROR;

As I think some of the design here is to run the trace even on the failure path?

Otherwise looks OK

Reviewed-by Jason Gunthorpe <[email protected]>

Jason

Quoted 125 lines · Leon Romanovsky

Changelog:
v4:
* Fixed kbuild error with mismatch in kmsan function declaration due to rebase error.
v3: https://lore.kernel.org/all/[email protected]
* Fixed typo in "cacheable" word
* Simplified kmsan patch a lot to be simple argument refactoring
v2: https://lore.kernel.org/all/[email protected]
* Used commit messages and cover letter from Jason
* Moved setting IOMMU_MMIO flag to dma_info_to_prot function
* Micro-optimized the code
* Rebased code on v6.17-rc1
v1: https://lore.kernel.org/all/[email protected]
* Added new DMA_ATTR_MMIO attribute to indicate PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path.
* Rewrote dma_map_* functions to use thus new attribute
v0: https://lore.kernel.org/all/[email protected]/
------------------------------------------------------------------------

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 maintains export symbol backward compatibility by keeping the old page-based API as wrapper functions around the new physical address-based implementations.

This series refactors the DMA mapping API to provide a phys_addr_t based, and struct-page free, external API that can handle all the mapping cases we want in modern systems:

- struct page based cachable DRAM
- struct page MEMORY_DEVICE_PCI_P2PDMA PCI peer to peer non-cachable MMIO
- struct page-less PCI peer to peer non-cachable MMIO
- struct page-less "resource" MMIO

Overall this gets much closer to Matthew's long term wish for struct-pageless IO to cachable DRAM. The remaining primary work would be in the mm side to allow kmap_local_pfn()/phys_to_virt() to work on phys_addr_t without a struct page.

The general design is to remove struct page usage entirely from the DMA API inner layers. For flows that need to have a KVA for the physical address they can use kmap_local_pfn() or phys_to_virt(). This isolates the struct page requirements to MM code only. Long term all removals of struct page usage are supporting Matthew's memdesc project which seeks to substantially transform how struct page works.

Instead make the DMA API internals work on phys_addr_t. Internally there are still dedicated 'page' and 'resource' flows, except they are now distinguished by a new DMA_ATTR_MMIO instead of by callchain. Both flows use the same phys_addr_t.

When DMA_ATTR_MMIO is specified things work similar to the existing 'resource' flow. kmap_local_pfn(), phys_to_virt(), phys_to_page(), pfn_valid(), etc are never called on the phys_addr_t. This requires rejecting any configuration that would need swiotlb. CPU cache flushing is not required, and avoided, as ATTR_MMIO also indicates the address have no cachable mappings. This effectively removes any DMA API side requirement to have struct page when DMA_ATTR_MMIO is used.

In the !DMA_ATTR_MMIO mode things work similarly to the 'page' flow, except on the common path of no cache flush, no swiotlb it never touches a struct page. When cache flushing or swiotlb copying kmap_local_pfn()/phys_to_virt() are used to get a KVA for CPU usage. This was already the case on the unmap side, now the map side is symmetric.

Callers are adjusted to set DMA_ATTR_MMIO. Existing 'resource' users must set it. The existing struct page based MEMORY_DEVICE_PCI_P2PDMA path must also set it. This corrects some existing bugs where iommu mappings for P2P MMIO were improperly marked IOMMU_CACHE.

Since ATTR_MMIO is made to work with all the existing DMA map entry points, particularly dma_iova_link(), this finally allows a way to use the new DMA API to map PCI P2P MMIO without creating struct page. The VFIO DMABUF series demonstrates how this works. This is intended to replace the incorrect driver use of dma_map_resource() on PCI BAR addresses.

This series does the core code and modern flows. A followup series will give the same treatment to the legacy dma_ops implementation.

Thanks

Leon Romanovsky (16):
dma-mapping: introduce new DMA attribute to indicate MMIO memory iommu/dma: implement DMA_ATTR_MMIO for dma_iova_link().
dma-debug: refactor to use physical addresses for page mapping
dma-mapping: rename trace_dma_*map_page to trace_dma_*map_phys iommu/dma: rename iommu_dma_*map_page to iommu_dma_*map_phys iommu/dma: extend iommu_dma_*map_phys API to handle MMIO memory
dma-mapping: convert dma_direct_*map_page to be phys_addr_t based
kmsan: convert kmsan_handle_dma to use physical addresses
dma-mapping: handle MMIO flow in dma_map|unmap_page
xen: swiotlb: Open code map_resource callback
dma-mapping: export new dma_*map_phys() interface mm/hmm: migrate to physical address-based DMA mapping API mm/hmm: properly take MMIO path
block-dma: migrate to dma_map_phys instead of map_page
block-dma: properly take MMIO path
nvme-pci: unmap MMIO pages with appropriate interface

  Documentation/core-api/dma-api.rst        |   4 +-
  Documentation/core-api/dma-attributes.rst |  18 ++++
  arch/powerpc/kernel/dma-iommu.c           |   4 +-
  block/blk-mq-dma.c                        |  15 ++-
  drivers/iommu/dma-iommu.c                 |  61 +++++------
  drivers/nvme/host/pci.c                   |  18 +++-
  drivers/virtio/virtio_ring.c              |   4 +-
  drivers/xen/swiotlb-xen.c                 |  21 +++-
  include/linux/blk-mq-dma.h                |   6 +-
  include/linux/blk_types.h                 |   2 +
  include/linux/dma-direct.h                |   2 -
  include/linux/dma-map-ops.h               |   8 +-
  include/linux/dma-mapping.h               |  33 ++++++
  include/linux/iommu-dma.h                 |  11 +-
  include/linux/kmsan.h                     |   9 +-
  include/trace/events/dma.h                |   9 +-
  kernel/dma/debug.c                        |  71 ++++---------
  kernel/dma/debug.h                        |  37 ++-----
  kernel/dma/direct.c                       |  22 +---

Quoted 8 lines

  kernel/dma/direct.h                       |  52 ++++++----
  kernel/dma/mapping.c                      | 117 +++++++++++++---------
  kernel/dma/ops_helpers.c                  |   6 +-
  mm/hmm.c                                  |  19 ++--
  mm/kmsan/hooks.c                          |   5 +-
  rust/kernel/dma.rs                        |   3 +
  tools/virtio/linux/kmsan.h                |   2 +-
  26 files changed, 305 insertions(+), 254 deletions(-)

Marek,

So what are the next steps here? This series is pre-requirement for the VFIO MMIO patches.

I would like to give those patches a try in linux-next, but in meantime I tested it on my test farm and found a regression in dma_map_resource() handling. Namely the dma_map_resource() is no longer possible with size not aligned to kmalloc()'ed buffer, as dma_direct_map_phys() calls dma_kmalloc_needs_bounce(),

Quoted 5 lines · Marek Szyprowski

I would like to give those patches a try in linux-next, but in meantime I tested it on my test farm and found a regression in dma_map_resource() handling. Namely the dma_map_resource() is no longer possible with size not aligned to kmalloc()'ed buffer, as dma_direct_map_phys() calls dma_kmalloc_needs_bounce(),

Hmm, it's this bit:

	capable = dma_capable(dev, dma_addr, size, !(attrs & DMA_ATTR_MMIO));
	if (unlikely(!capable) || dma_kmalloc_needs_bounce(dev, size, dir)) {
		if (is_swiotlb_active(dev) && !(attrs & DMA_ATTR_MMIO))
			return swiotlb_map(dev, phys, size, dir, attrs);

		goto err_overflow;
	}

We shouldn't be checking dma_kmalloc_needs_bounce() on mmio as there is no cache flushing so the "dma safe alignment" for non-coherent DMA does not apply.

Like you say looks good to me, and more of the surrouding code can be pulled in too, no sense in repeating the boolean logic:

	if (attrs & DMA_ATTR_MMIO) {
		dma_addr = phys;
		if (unlikely(!dma_capable(dev, dma_addr, size, false)))
			goto err_overflow;
	} else {
		dma_addr = phys_to_dma(dev, phys);
		if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||

		    dma_kmalloc_needs_bounce(dev, size, dir)) {
			if (is_swiotlb_active(dev))
				return swiotlb_map(dev, phys, size, dir, attrs);

			goto err_overflow;
		}
		if (!dev_is_dma_coherent(dev) &&
		    !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
			arch_sync_dma_for_device(phys, size, dir);
	}

Jason

From: Leon Romanovsky <[email protected]>

After introduction of dma_map_phys(), there is no need to convert from physical address to struct page in order to map page. So let's use it directly.

Signed-off-by Leon Romanovsky <[email protected]>

---
  block/blk-mq-dma.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

block/blk-mq-dma.c +0 -0

index ad283017caef..37e2142be4f7 100644

block/blk-mq-dma.c static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec) · line 94

Quoted 11 lines · Leon Romanovsky

block/blk-mq-dma.c +2 -2

@@ -87,8 +87,8 @@ static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec)
  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));
+	iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len,
+			rq_dma_dir(req), 0);
  	if (dma_mapping_error(dma_dev, iter->addr)) {
  		iter->status = BLK_STS_RESOURCE;
  		return false;

I wonder where is the corresponding dma_unmap_page() call and its change to dma_unmap_phys()...

Quoted 15 lines · Marek Szyprowski

block/blk-mq-dma.c static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec) · line 94

Quoted 11 lines · Leon Romanovsky

block/blk-mq-dma.c +2 -2

@@ -87,8 +87,8 @@ static bool blk_dma_map_bus(struct blk_dma_iter *iter, struct phys_vec *vec)
  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));
+	iter->addr = dma_map_phys(dma_dev, vec->paddr, vec->len,
+			rq_dma_dir(req), 0);
  	if (dma_mapping_error(dma_dev, iter->addr)) {
  		iter->status = BLK_STS_RESOURCE;
  		return false;

I wonder where is the corresponding dma_unmap_page() call and its change to dma_unmap_phys()...

You can't do that in the generic layer, so it's up to the caller. The dma addrs that blk_dma_iter yield are used in a caller specific structure. For example, for NVMe, it goes into an NVMe PRP. The generic layer doesn't know what that is, so the driver has to provide the unmapping.

Quoted 2 lines · Leon Romanovsky

This series does the core code and modern flows. A followup series will give the same treatment to the legacy dma_ops implementation.

I took a quick check over this to see that it is sane. I think using phys is an improvement for most of the dma_ops implemenations.

arch/sparc/kernel/pci_sun4v.c arch/sparc/kernel/iommu.c
Uses __pa to get phys from the page, never touches page

arch/alpha/kernel/pci_iommu.c
arch/sparc/mm/io-unit.c
drivers/parisc/ccio-dma.c
drivers/parisc/sba_iommu.c
Does page_addres() and later does __pa on it. Doesn't touch struct page

arch/x86/kernel/amd_gart_64.c drivers/xen/swiotlb-xen.c
arch/mips/jazz/jazzdma.c
Immediately does page_to_phys(), never touches struct page

drivers/vdpa/vdpa_user/vduse_dev.c
Does page_to_phys() to call iommu_map()

drivers/xen/grant-dma-ops.c
Does page_to_pfn() and nothing else

arch/powerpc/platforms/ps3/system-bus.c
This is a maze but I think it wants only phys and the virt is only used for debug prints.

The above all never touch a KVA and just want a phys_addr_t.

The below are touching the KVA somehow:

arch/sparc/mm/iommu.c
arch/arm/mm/dma-mapping.c
Uses page_address to cache flush, would be happy with phys_to_virt() and a PhysHighMem()

arch/powerpc/kernel/dma-iommu.c arch/powerpc/platforms/pseries/vio.c
Uses iommu_map_page() which wants phys_to_virt(), doesn't touch struct page

arch/powerpc/platforms/pseries/ibmebus.c
Returns phys_to_virt() as dma_addr_t.

The two PPC ones are weird, I didn't figure out how that was working..

It would be easy to make map_phys patches for about half of these, in the first grouping. Doing so would also grant those arches map_resource capability.

Overall I didn't think there was any reduction in maintainability in these places. Most are improvements eliminating code, and some are just switching to phys_to_virt() from page_address(), which we could further guard with DMA_ATTR_MMIO and a check for highmem.

From: Leon Romanovsky <[email protected]>

Convert the DMA debug infrastructure from page-based to physical address-based mapping as a preparation to rely on physical address for DMA mapping routines.

The refactoring renames debug_dma_map_page() to debug_dma_map_phys() and changes its signature to accept a phys_addr_t parameter instead of struct page and offset. Similarly, debug_dma_unmap_page() becomes debug_dma_unmap_phys(). A new dma_debug_phy type is introduced to distinguish physical address mappings from other debug entry types. All callers throughout the codebase are updated to pass physical addresses directly, eliminating the need for page-to-physical conversion in the debug layer.

This refactoring eliminates the need to convert between page pointers and physical addresses in the debug layer, making the code more efficient and consistent with the DMA mapping API's physical address focus.

Reviewed-by Jason Gunthorpe <[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

---
  Documentation/core-api/dma-api.rst |  4 ++--
  kernel/dma/debug.c                 | 28 +++++++++++++++++-----------
  kernel/dma/debug.h                 | 16 +++++++---------
  kernel/dma/mapping.c               | 15 ++++++++-------
  4 files changed, 34 insertions(+), 29 deletions(-)

Documentation/core-api/dma-api.rst +2 -2

index 3087bea715ed..ca75b3541679 100644
@@ -761,7 +761,7 @@ example warning message may look like this::
  	[<ffffffff80235177>] find_busiest_group+0x207/0x8a0
  	[<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50
  	[<ffffffff803c7ea3>] check_unmap+0x203/0x490
-	[<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50
+	[<ffffffff803c8259>] debug_dma_unmap_phys+0x49/0x50
  	[<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0
  	[<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0
  	[<ffffffff8026df84>] handle_IRQ_event+0x34/0x70

@@ -855,7 +855,7 @@ that a driver may be leaking mappings.
  dma-debug interface debug_dma_mapping_error() to debug drivers that fail
  to check DMA mapping errors on addresses returned by dma_map_single() and
  dma_map_page() interfaces. This interface clears a flag set by
-debug_dma_map_page() to indicate that dma_mapping_error() has been called by
+debug_dma_map_phys() to indicate that dma_mapping_error() has been called by
  the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
  this flag is still set, prints warning message that includes call trace that
  leads up to the unmap. This interface can be called from dma_mapping_error()

kernel/dma/debug.c +17 -11

index e43c6de2bce4..da6734e3a4ce 100644
@@ -39,6 +39,7 @@ enum {
  	dma_debug_sg,
  	dma_debug_coherent,
  	dma_debug_resource,
+	dma_debug_phy,
  };
 
  enum map_err_types {

@@ -141,6 +142,7 @@ static const char *type2name[] = {
  	[dma_debug_sg] = "scatter-gather",
  	[dma_debug_coherent] = "coherent",
  	[dma_debug_resource] = "resource",
+	[dma_debug_phy] = "phy",
  };
 
  static const char *dir2name[] = {

@@ -1201,9 +1203,8 @@ void debug_dma_map_single(struct device *dev, const void *addr,
  }
  EXPORT_SYMBOL(debug_dma_map_single);
 
-void debug_dma_map_page(struct device *dev, struct page *page, size_t offset,
-			size_t size, int direction, dma_addr_t dma_addr,
-			unsigned long attrs)
+void debug_dma_map_phys(struct device *dev, phys_addr_t phys, size_t size,
+		int direction, dma_addr_t dma_addr, unsigned long attrs)
  {
  	struct dma_debug_entry *entry;
 

@@ -1218,19 +1219,24 @@ void debug_dma_map_page(struct device *dev, struct page *page, size_t offset,
  		return;
 
  	entry->dev       = dev;
-	entry->type      = dma_debug_single;
-	entry->paddr	 = page_to_phys(page) + offset;
+	entry->type      = dma_debug_phy;
+	entry->paddr	 = phys;
  	entry->dev_addr  = dma_addr;
  	entry->size      = size;
  	entry->direction = direction;
  	entry->map_err_type = MAP_ERR_NOT_CHECKED;
 
-	check_for_stack(dev, page, offset);
+	if (!(attrs & DMA_ATTR_MMIO)) {
+		struct page *page = phys_to_page(phys);
+		size_t offset = offset_in_page(page);
 
-	if (!PageHighMem(page)) {
-		void *addr = page_address(page) + offset;
+		check_for_stack(dev, page, offset);
 
-		check_for_illegal_area(dev, addr, size);
+		if (!PageHighMem(page)) {
+			void *addr = page_address(page) + offset;
+
+			check_for_illegal_area(dev, addr, size);
+		}
  	}
 
  	add_dma_entry(entry, attrs);

@@ -1274,11 +1280,11 @@ void debug_dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
  }
  EXPORT_SYMBOL(debug_dma_mapping_error);
 
-void debug_dma_unmap_page(struct device *dev, dma_addr_t dma_addr,
+void debug_dma_unmap_phys(struct device *dev, dma_addr_t dma_addr,
  			  size_t size, int direction)
  {
  	struct dma_debug_entry ref = {
-		.type           = dma_debug_single,
+		.type           = dma_debug_phy,
  		.dev            = dev,
  		.dev_addr       = dma_addr,
  		.size           = size,

kernel/dma/debug.h +7 -9

index f525197d3cae..76adb42bffd5 100644
@@ -9,12 +9,11 @@
  #define _KERNEL_DMA_DEBUG_H
 
  #ifdef CONFIG_DMA_API_DEBUG
-extern void debug_dma_map_page(struct device *dev, struct page *page,
-			       size_t offset, size_t size,
-			       int direction, dma_addr_t dma_addr,
+extern void debug_dma_map_phys(struct device *dev, phys_addr_t phys,
+			       size_t size, int direction, dma_addr_t dma_addr,
  			       unsigned long attrs);
 
-extern void debug_dma_unmap_page(struct device *dev, dma_addr_t addr,
+extern void debug_dma_unmap_phys(struct device *dev, dma_addr_t addr,
  				 size_t size, int direction);
 
  extern void debug_dma_map_sg(struct device *dev, struct scatterlist *sg,

@@ -55,14 +54,13 @@ extern void debug_dma_sync_sg_for_device(struct device *dev,
  					 struct scatterlist *sg,
  					 int nelems, int direction);
  #else /* CONFIG_DMA_API_DEBUG */
-static inline void debug_dma_map_page(struct device *dev, struct page *page,
-				      size_t offset, size_t size,
-				      int direction, dma_addr_t dma_addr,
-				      unsigned long attrs)
+static inline void debug_dma_map_phys(struct device *dev, phys_addr_t phys,
+				      size_t size, int direction,
+				      dma_addr_t dma_addr, unsigned long attrs)
  {
  }
 
-static inline void debug_dma_unmap_page(struct device *dev, dma_addr_t addr,
+static inline void debug_dma_unmap_phys(struct device *dev, dma_addr_t addr,
  					size_t size, int direction)
  {
  }

kernel/dma/mapping.c +7 -6

index 107e4a4d251d..4c1dfbabb8ae 100644
@@ -157,6 +157,7 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
  		unsigned long attrs)
  {
  	const struct dma_map_ops *ops = get_dma_ops(dev);
+	phys_addr_t phys = page_to_phys(page) + offset;
  	dma_addr_t addr;
 
  	BUG_ON(!valid_dma_direction(dir));

@@ -165,16 +166,15 @@ dma_addr_t dma_map_page_attrs(struct device *dev, struct page *page,
  		return DMA_MAPPING_ERROR;
 
  	if (dma_map_direct(dev, ops) ||
-	    arch_dma_map_page_direct(dev, page_to_phys(page) + offset + size))
+	    arch_dma_map_page_direct(dev, phys + size))
  		addr = dma_direct_map_page(dev, page, offset, size, dir, attrs);
  	else if (use_dma_iommu(dev))
  		addr = iommu_dma_map_page(dev, page, offset, size, dir, attrs);
  	else
  		addr = ops->map_page(dev, page, offset, size, dir, attrs);
  	kmsan_handle_dma(page, offset, size, dir);
-	trace_dma_map_page(dev, page_to_phys(page) + offset, addr, size, dir,
-			   attrs);
-	debug_dma_map_page(dev, page, offset, size, dir, addr, attrs);
+	trace_dma_map_page(dev, phys, addr, size, dir, attrs);
+	debug_dma_map_phys(dev, phys, size, dir, addr, attrs);
 
  	return addr;
  }

@@ -194,7 +194,7 @@ void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr, size_t size,
  	else
  		ops->unmap_page(dev, addr, size, dir, attrs);
  	trace_dma_unmap_page(dev, addr, size, dir, attrs);
-	debug_dma_unmap_page(dev, addr, size, dir);
+	debug_dma_unmap_phys(dev, addr, size, dir);
  }
  EXPORT_SYMBOL(dma_unmap_page_attrs);
 

@@ -712,7 +712,8 @@ struct page *dma_alloc_pages(struct device *dev, size_t size,
  	if (page) {
  		trace_dma_alloc_pages(dev, page_to_virt(page), *dma_handle,
  				      size, dir, gfp, 0);
-		debug_dma_map_page(dev, page, 0, size, dir, *dma_handle, 0);
+		debug_dma_map_phys(dev, page_to_phys(page), size, dir,
+				   *dma_handle, 0);
  	} else {
  		trace_dma_alloc_pages(dev, NULL, 0, size, dir, gfp, 0);
  	}

Quoted 51 lines · Jason Gunthorpe

Quoted 2 lines · Leon Romanovsky

This series does the core code and modern flows. A followup series will give the same treatment to the legacy dma_ops implementation.

I took a quick check over this to see that it is sane. I think using phys is an improvement for most of the dma_ops implemenations.

arch/sparc/kernel/pci_sun4v.c arch/sparc/kernel/iommu.c
Uses __pa to get phys from the page, never touches page

arch/alpha/kernel/pci_iommu.c
arch/sparc/mm/io-unit.c
drivers/parisc/ccio-dma.c
drivers/parisc/sba_iommu.c
Does page_addres() and later does __pa on it. Doesn't touch struct page

arch/x86/kernel/amd_gart_64.c drivers/xen/swiotlb-xen.c
arch/mips/jazz/jazzdma.c
Immediately does page_to_phys(), never touches struct page

drivers/vdpa/vdpa_user/vduse_dev.c
Does page_to_phys() to call iommu_map()

drivers/xen/grant-dma-ops.c
Does page_to_pfn() and nothing else

arch/powerpc/platforms/ps3/system-bus.c
This is a maze but I think it wants only phys and the virt is only used for debug prints.

The above all never touch a KVA and just want a phys_addr_t.

The below are touching the KVA somehow:

arch/sparc/mm/iommu.c
arch/arm/mm/dma-mapping.c
Uses page_address to cache flush, would be happy with phys_to_virt() and a PhysHighMem()

arch/powerpc/kernel/dma-iommu.c arch/powerpc/platforms/pseries/vio.c
Uses iommu_map_page() which wants phys_to_virt(), doesn't touch struct page

arch/powerpc/platforms/pseries/ibmebus.c
Returns phys_to_virt() as dma_addr_t.

The two PPC ones are weird, I didn't figure out how that was working..

Quoted 8 lines

It would be easy to make map_phys patches for about half of these, in the first grouping. Doing so would also grant those arches map_resource capability.

Overall I didn't think there was any reduction in maintainability in these places. Most are improvements eliminating code, and some are just switching to phys_to_virt() from page_address(), which we could further guard with DMA_ATTR_MMIO and a check for highmem.

Thanks for this summary.

However I would still like to get an answer for the simple question - why all this work cannot be replaced by a simple use of dma_map_resource()?

I've checked the most advertised use case in
https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-vfio
and I still don't see the reason why it cannot be based
on dma_map_resource() API? I'm aware of the little asymmetry of the client calls is such case, indeed it is not preety, but this should work even now:

phys = phys_vec[i].paddr;

if (is_mmio)
    dma_map_resource(phys, len, ...);
else
    dma_map_page(phys_to_page(phys), offset_in_page(phys), ...);

What did I miss?

I'm not against this rework, but I would really like to know the rationale. I know that the 2-step dma-mapping API also use phys addresses and this is the same direction.

I've checked the most advertised use case in
https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-vfio
and I still don't see the reason why it cannot be based
on dma_map_resource() API? I'm aware of the little asymmetry of the client calls is such case, indeed it is not preety, but this should work even now:

phys = phys_vec[i].paddr;

if (is_mmio)
    dma_map_resource(phys, len, ...);
else
    dma_map_page(phys_to_page(phys), offset_in_page(phys), ...);

What did I miss?

This patchset focuses only on the dma_map_page -> dma_map_phys rework. There are also other interfaces, like dma_alloc_pages() and so far nothing has been proposed for them so far.

There is only one user I found of alloc_pages:

drivers/firewire/ohci.c: ctx->pages[i] = dma_alloc_pages(dev, PAGE_SIZE, &dma_addr,

And it deliberately uses page->private:

		set_page_private(ctx->pages[i], dma_addr);

So it is correct to use the struct page API.

Hi,

I'm a present maintainer of Linux FireWire subsystem, and recent years have been working to modernize the subsystem.

Quoted 6 lines · Jason Gunthorpe

There is only one user I found of alloc_pages:

drivers/firewire/ohci.c: ctx->pages[i] = dma_alloc_pages(dev, PAGE_SIZE, &dma_addr,

And it deliberately uses page->private:

Quoted 3 lines

		set_page_private(ctx->pages[i], dma_addr);

So it is correct to use the struct page API.

I've already realized it, and it is in my TODO list to use modern alternative APIs to replace it (but not yet). If you know some candidates for this purpose, it is really helpful to accomplish it.