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 40ECBC77B7F for ; Fri, 27 Jun 2025 17:02:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA6D66B00B3; Fri, 27 Jun 2025 13:02:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7EDC6B00B8; Fri, 27 Jun 2025 13:02:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BB7B6B00B9; Fri, 27 Jun 2025 13:02:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8B7D36B00B3 for ; Fri, 27 Jun 2025 13:02:21 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 15029B7C79 for ; Fri, 27 Jun 2025 17:02:21 +0000 (UTC) X-FDA: 83601798882.01.C3F793E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id 5BA3220019 for ; Fri, 27 Jun 2025 17:02:19 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tvSgedwL; spf=pass (imf03.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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751043739; 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=9bOe/JCswOnU7WdYHYnhxKuhHMqv5b1veFJCuFWhDL8=; b=VzBHyfaD0AOZ4Kf9DOoZFhPZDWa91W+WgjEE6raWZyiroirPVr3+cWbuRoMtZaD0lzz8gr vGC5fWhkAPtovDQoX0skD8s1RF7fE+pK+FsZKiQytHJZW5cdVphJf/XrCs8XYmQDky3NSq fkvLeJ0TMMJTsTvtk4GuCGaB7WWJlwM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tvSgedwL; spf=pass (imf03.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=1751043739; a=rsa-sha256; cv=none; b=3/G0+NrYt+U9fONWVqW49wH/N/x/m/ehBnceml0U75DIWJNtaE0MEgPvu+ji2HnXtGKgJ/ ie94pqwEOx+3kmglMImKMqJhdIouZSUmWyOZ4nXnpRBj45Nof+Zk+wpzA6k1DPJAtbIGxI 5J2TNzpL3uAi1ZV/WpWGvEIIJseR2+c= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 52EEE5C6AAF; Fri, 27 Jun 2025 17:02:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55EE2C4CEE3; Fri, 27 Jun 2025 17:02:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751043738; bh=tYzCzCM3VZZF7WSTA7gi5cm/krCk6YzEM9VmpLpknjY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tvSgedwLkGNl0rMmzrS3+y77Cdl6mvdnS/K1+GmEohvH0tjCCcyHtHpGONE48PbuE klXY+q4z8M1Sr6BMdy5xKLE+7d0yKqmUTsHjPtcmxh4vJJtZd+k3yW/hyDz3WRQrN7 9wzjcEy3jjvepJtDybVtHKrX2dD+yzLWynuamatcAKtm3zUP2H46mTYvoCARqj66Pz 6UkaSbTPpQWjV9eejBMr9V3CGDdGIUzKXNzrhwjf9KcP57JXzI9oiJZKCpv4d77ArY EG95TYcKm5S2WkFdvbxGcvfwd6s5pEsCWXf4aKpX4Whf3v+9N/L6udSPyAT+368SB1 8wWh+cVapuQEw== Date: Fri, 27 Jun 2025 20:02:13 +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: <20250627170213.GL17401@unreal> References: <35df6f2a-0010-41fe-b490-f52693fe4778@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35df6f2a-0010-41fe-b490-f52693fe4778@samsung.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5BA3220019 X-Stat-Signature: mp7yb78ccbxtg87bshwrq36sd8u7q7j4 X-HE-Tag: 1751043739-839346 X-HE-Meta: U2FsdGVkX1/3UmaRETLgobH8R0oPble0EzRTeBeJGULDaUoJ1tHKPyzQCJW8oACAiJjGdwZzEVVsfwIkr8f1jtUo6T50lKpO8d4S+T8ppd0uL3En+teeDB40XA4J79dxYoxvrAxkBAH71t1hk2nrHU5hFZs3eQALTVd3QLG+rR6xTZXVgovPe0O3eyACdmcOE9PdTMKPQFQtd+eGR2riKduyfaWi8fhStNkPQYyqzwF+7nKhQDZW9OzKvTkQnfle1WTXtQD6VS+sSWwS6ZdgLvc1F6yOxSqZ41R4WbIDhhiA6LvyzRDEG1neRJ1d7Uu+tqIByHy2aLS5UkAXhxJKgLEy8lKvhY6404vDIMTAHWc7fYe+cjV80QmBbEljhLmt04wG/VV8y4teVrbY1gxDia5vg0i+zFzJVLgLoyhgYLo0ALYeDlZBq33+FDWWuDJu4iMiD5RFJHcgrI60EAHrw07HCWtELfvzrNeSJO0qPvIlvZ5aGJfO+XLssoU5K9YDsubDk/rHvoiqZSA7686kpEkP8/JSc9ey3q6xtIW8xBQJfFibr5fdg7jG+zMFL7wcrHybvLUXNTsuiDc4G/gG08fvfgRcOoNhQFcj6wOjRa8D67tLFKwo96d51LJrtTfmCOqGtXddrHNX0yTfP01g8pAKlqWPyZ/DAMbqDuputllJWqmAhoiCXiB+Nc1VAWaA6fWKm8ZSPJsgCnygREMbiJiHCLA9fyM587HPg/n76PiIK3FjLcxa9eyAFvJtrNLpV3OfuvuWcF/q+dLfadI6LFXUxthn4OoIrjyBLoBA52dgMR+gmvVbNNMbHp2iknVBWeCego/Fdjxu49q0QfcPAX6KwsOj1DRMeXLBF/QkwEyU885KFndIUH3jaKII6Trd6KlGL5z09EK0L8as5iGqyjvTDsngQfS0Q8k5sYl/kWd1X0/HnXxMKFxUA3CANgL8sMRv+uFVhzQqrI4c7Ty AKM5M+RA FzCUcsbdmH7SXjTrmfhvk5pNBa4S8sKov7zM2ARiI5a2IsA6dYH+8NHT4P5dfZ4omM6idoUjm1cRPZGcIWfKoYZL5Z0JkWfDStuNDggGJOzAn0RD1C2IJL/FaLE09g51HJuDf3J8+UWFTa93r4vqbO2keYHAoCVgrrG3gUrzdCoGhm1w4r6PLuYbIljymmreTLZ63SEZfWY2Ez8tWVqG/a22+eSiHcNS+VpWAi6Dr9RfyZ0wkSoq39IxupbJ0mv9U03qV5kXpyN59qm8S7EALf+4Nhwf9rg3Wi0rNNgOOvSTS4OQ= 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 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 > >