From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D29EC83F05 for ; Sun, 6 Jul 2025 06:00:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B1A46B8074; Sun, 6 Jul 2025 02:00:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 163186B8067; Sun, 6 Jul 2025 02:00:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0531C6B8074; Sun, 6 Jul 2025 02:00:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id DE4EC6B8067 for ; Sun, 6 Jul 2025 02:00:15 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4D5D8C2962 for ; Sun, 6 Jul 2025 06:00:15 +0000 (UTC) X-FDA: 83632789590.26.C59F071 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id BBBD3140002 for ; Sun, 6 Jul 2025 06:00:13 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rGudv65b; spf=pass (imf23.hostedemail.com: domain of leon@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=leon@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rGudv65b; spf=pass (imf23.hostedemail.com: domain of leon@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=leon@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751781613; a=rsa-sha256; cv=none; b=YzulpPNbcpOYXtFEz0E5nX8urncP0IdYdVySr5mNHircTiTtq3GR0qa66ArcIiy5a9nqzl tQwfFOv7hF6virwHStKrBnmqZGcm7ZX5KNznRWHbO4QBg84alpL46BsCQE6WBEM2SvTPzO wlXPhD6Dz0Odu3mwYCkr71dRuzhg+1I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751781613; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fIoE9h1Ttmus+8dX+kExs7d3ndPa3iTpWbO6DspI45k=; b=YTErTsjwQzyjbVkOw4MimqjREirE5cP5NQ6Gg7suDoNFyppV7kihofeyJXokUg3TwqAm8s 0AUMgKGWVPrfhK38PmD44l5TScs/9V/Jx2v2Y1/yu6mfzUkIOWaWTOGE/gQE+tmqX41bRw kUsgrvJNz4evoR3C9G2Czle5QazMmnw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 697605C4B3B; Sun, 6 Jul 2025 06:00:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5853DC4CEED; Sun, 6 Jul 2025 06:00:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751781612; bh=6LXeYQHiR9KdMFnH25UR1nczxh0conAegX4pfPWuIkE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rGudv65bW/I8lfKVqqK+2DB/GumrSqAs4KGqsf9lwb5vIM0lf5rqwLOiBIWp47ysv 4r0WG7tURWg1tGnjjq79aeVVQsZyXGj8cR1nXlmSb/tIyQdxWa5jBPwYgk4Ibn8/K9 8aclrjMylHDqCzPAf4qXddw9XneKJKYKYM0CiGX5G6xkO/XRKoQ3qrE6gYkXOWmNgu 3ThVFn2essmngu1U6ie6u/JjbUhg1oKvSHUs8gt+5x+lYChW6F8Iwx5TWrOW2nYZQ7 U+zyKgjP6FtLwjG/hLHgAU67WZV0PzQ/Jx8mTjGv1yy23vzA7uiG8kCNLs0kGzeagw h+sF92nUwh5Nw== Date: Sun, 6 Jul 2025 09:00:07 +0300 From: Leon Romanovsky To: Marek Szyprowski Cc: Christoph Hellwig , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Robin Murphy , Joerg Roedel , Will Deacon , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , Alexander Potapenko , Marco Elver , Dmitry Vyukov , Masami Hiramatsu , Mathieu Desnoyers , =?iso-8859-1?B?Suly9G1l?= Glisse , Andrew Morton , 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 Subject: Re: [PATCH 0/8] dma-mapping: migrate to physical address-based API Message-ID: <20250706060007.GP6278@unreal> References: <35df6f2a-0010-41fe-b490-f52693fe4778@samsung.com> <20250627170213.GL17401@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250627170213.GL17401@unreal> X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: BBBD3140002 X-Stat-Signature: uxtnw5h9ciwiexsn99jrzgp15r5phija X-Rspam-User: X-HE-Tag: 1751781613-548574 X-HE-Meta: U2FsdGVkX18FhQrnUFYako18o9+YUC7DOMP6Kzg4GujWrmos4vjuThfIxEoSDAfbl+qjzCfhF29ukJ1qC4Z/lpfALHqIeK53WUcSSZx9ORP0H0LkdEtLP6GSxzRqvjSdSR+6pToCsFU7bekJk3HtRL0tQqBRINsVkzTiODvZvQLKQjrSXpaTvV5c65ldBH2RmG6Hr1HEG1zUkntkvj+WDZbwaNRKaWjkKQmnhk6IRbCH/0R75496e+f8ySEuFZxysKyBCmtx5YmZYXJrG5dEYWgF1YxOnued2oVjI5Gb67Vk9bUbUyvrF3t29XlgEaOBtvOEdOwJowS5NwSnjyfl6fyi99Jo7PKgBiCHg9wwDTTp3WFwXWbFEccSqQFOoA5RIjji9JP0Ea8/r2uMOEGjVJLqbiqT0UgVbOWwjVWs9N3gDxNjtDcsp4o6N4Sm/Zj1vnEmoNQmEgAstAGJ3kqp/+2EZCUTy7cRCFKkJuuPstRU1LgH1Oku2vVaxz5rz7nGMdAl5Mv/zktutFDRvAych6Tiq6JFm5Q6Tc6JBLerKJ3mdGr6mNTXh8roAK2KCVf26ugPUUg9XOKWb4IHvC35ewYWeTbM6gudHWg6hSr5Y8t6hNBYakHCOm6fUM0sQr/Yh5udU/bFmReBVo7cwJoMlUUIpaSmqik29xhQlefMyDqRwtXamrDFiAuPhBCG2AVtaVwZZmPlhc1/d45xlPhaA8s4DLdQZiW8YV/EjWJbaUZQ2p18m3yA5UdZYRPuQeDq/e9P5hHqkGKdCgXVSwVcGd1YBXSRY130oJfE0pf9XR+xRE8vdMXsemPs3JNPSc0s78YxgE5qQXdbnSX59AS89jGWcOPG7R6ofKQHsS79gu8Yl+wU/78xWkAVOU903gPpZEt2JrgQnCD8V6Mj3zGw2Kb6/IUbyyceg9mKSkDccnomxYLX11gN7A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jun 27, 2025 at 08:02:13PM +0300, Leon Romanovsky wrote: > 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. I almost completed main user of this dma_map_phys() callback. It is rewrite of this patch [PATCH v3 3/3] vfio/pci: Allow MMIO regions to be exported through dma-buf https://lore.kernel.org/all/20250307052248.405803-4-vivek.kasireddy@intel.com/ Whole populate_sgt()->dma_map_resource() block looks differently now and it is relying on dma_map_phys() as we are exporting memory without struct pages. It will be something like this: 89 for (i = 0; i < priv->nr_ranges; i++) { 90 phys = pci_resource_start(priv->vdev->pdev, 91 dma_ranges[i].region_index); 92 phys += dma_ranges[i].offset; 93 94 if (priv->bus_addr) { 95 addr = pci_p2pdma_bus_addr_map(&p2pdma_state, phys); 96 fill_sg_entry(sgl, dma_ranges[i].length, addr); 97 sgl = sg_next(sgl); 98 } else if (dma_use_iova(&priv->state)) { 99 ret = dma_iova_link(attachment->dev, &priv->state, phys, 100 priv->mapped_len, 101 dma_ranges[i].length, dir, attrs); 102 if (ret) 103 goto err_unmap_dma; 104 105 priv->mapped_len += dma_ranges[i].length; 106 } else { 107 addr = dma_map_phys(attachment->dev, phys, 0, 108 dma_ranges[i].length, dir, attrs); 109 ret = dma_mapping_error(attachment->dev, addr); 110 if (ret) 111 goto unmap_dma_buf; 112 113 fill_sg_entry(sgl, dma_ranges[i].length, addr); 114 sgl = sg_next(sgl); 115 } 116 } 117 118 if (dma_use_iova(&priv->state) && !priv->bus_addr) { 119 ret = dma_iova_sync(attachment->dev, &pri->state, 0, 120 priv->mapped_len); 121 if (ret) 122 goto err_unmap_dma; 123 124 fill_sg_entry(sgl, priv->mapped_len, priv->state.addr); 125 } > > > 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. It is not needed for now, all p2p logic is external to DMA API. Thanks > > > > Best regards > > -- > > Marek Szyprowski, PhD > > Samsung R&D Institute Poland > > > > >