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 9A6CDC83F2D for ; Tue, 15 Jul 2025 13:58:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3603D8D0014; Tue, 15 Jul 2025 09:58:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 310D18D0001; Tue, 15 Jul 2025 09:58:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 227B48D0014; Tue, 15 Jul 2025 09:58:39 -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 0C06B8D0001 for ; Tue, 15 Jul 2025 09:58:39 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CE58B591A2 for ; Tue, 15 Jul 2025 13:58:38 +0000 (UTC) X-FDA: 83666654316.01.A813A53 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf14.hostedemail.com (Postfix) with ESMTP id 3663410000D for ; Tue, 15 Jul 2025 13:58:37 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=l4Vizggn; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of leon@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=leon@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752587917; a=rsa-sha256; cv=none; b=UC4YOliIEvjEzTUKC5p17NMYeOIRu4VD1qR8U7g4H2WDxu3KRZf4mqAyCkOxJBTzacNPNe CMw15Krzrur8IttuMdFkmObY92pdmpaV/S8vec405NIHWxODGE0rfPvDA3rW35o4zXT3QV 0ue6aUVfqey6ysLntYM5opA6oVYiuMY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=l4Vizggn; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of leon@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=leon@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752587917; 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=6nnCBwHTAKrHqcmaMGyNrB/ejXN9Xrce25gHVuAIWJI=; b=EBbt6dSF9aajlJNgqfTkKKukpi6SGaVw9q3I7Q/rXdKxYzUbYgMuwekMMh+rJl/5vDxcIw X0YMbeQ6BIxNAdvWuhJk2mfyyL95uBh1l3DNPnKj0b+6hMWwS6AMNf0Yfl+g9DJLyacM8i Cj2bq1/ze7pDjP7OjjowEWC2TPXPh2Y= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 9366FA5710B; Tue, 15 Jul 2025 13:58:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E39CC4CEE3; Tue, 15 Jul 2025 13:58:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752587913; bh=fxS+g8tNbMk1/UdhRU/HlLfSUskJDrVIrYOCQQhuqIY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l4VizggnWo1DpwbZuWP/wgm3VApTeTCEOnymfwBXT+GilXimDEQE0iPIBqdfv6kCi kvrSMjoaH00P8jMdB4VBav7nnidtnHwAto4lOKuhIXdRUv9zLac0k9qGP1dt9vU+Kx besMzcLyEY6CL3CXJ/iulu2Ux2wmI6rIlbokZUIfssTq+7xCt4aR4/gUg5F8zwheNy 38Z2YuBFkCPHKo42aC2RxBV7YCSsmJFp5Nn2VHoOI+x4EAhgotJS6lFClihLkokNmk clpPZozDwuZYTrNm/DjfETz/I7kal1xj7ibFiF39RZ8jyeg3fbnaBQWAnL0Q+x4geu jTleqek0Z+P7g== Date: Tue, 15 Jul 2025 16:58:28 +0300 From: Leon Romanovsky To: Will Deacon Cc: Marek Szyprowski , Christoph Hellwig , Jonathan Corbet , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Robin Murphy , Joerg Roedel , "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 Subject: Re: [PATCH 8/8] mm/hmm: migrate to physical address-based DMA mapping API Message-ID: <20250715135828.GE5882@unreal> References: <8a85f4450905fcb6b17d146cc86c11410d522de4.1750854543.git.leon@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3663410000D X-Stat-Signature: qbnesde8kp5m4mcde3nwntggzap3zcdm X-Rspam-User: X-HE-Tag: 1752587917-958173 X-HE-Meta: U2FsdGVkX19GKZZ1XO8eFTq3dt6BFSAruRN6n8BHcEWZUgpZUTt5uPP+7r2IxGQakzB1PZOpyTKgnFZn1CEEsATXsaVHXT8C2wx67ShcdeXI97+GzX+uUxjg4oo6JTWEHGFuiTJOh+57zrkQCFN40JxnoXQyUR0vbQVRc3QIFlTYdnHOV9t5Q2cKR+siyoKvvlWgYa/z5M0hdrhOUkWzwxmJz65bE09/WEXQ0L/Ztm6j4FADRdo3zxhGQYTuCLlAKlSFTCodcW8sk+DnTtYjpLokf0T0iByekFf3wxVXcojYesvxjX+UIkDcCQJ3n5j12YTKT8y0oQHJ9pvkN7agQEBILnqeEV8MHzaGKZ+4GPDY5OvbFqaJq9Nid/8yt4ry47K739TAd95+0v/jHnNkMioLkDocwmjEL52sfoYgJDZVSdnpoLsetVll9OoY6zZKZw4fdP/desJKOEwz6xM8SovduztbS9vfM0C8o08x8dlu1wrr3Sng0No2QS3BHGhEhBqdefsViiQ3gsVnqZXmRTmKxkB30wWWbGIb9mbThejQeOmnFQsHZCc3GTB2DG/ly5kLk7hiXtQiS+ce9Ea/v7+vvsQnPAIG1Xpq1cDPqtDLXtdvroWJFvwhHz3+J8T0n/75H8v7gwzG2IRjjt6waj5PmOsCpifZFenQUJzuHOV3m6MK8PyKUe8MQvNgMRJ91y4cZP5xO8+mI8qeVmZJlf30jqZ7nOl6edCf9EUrRyrSs77h4BEDTyN30urkkAx4Trgz/Ws4c26lBmfpozbSB39+GfMc3luOxhO/lSjz3mnIlowWHwkvnBCOMxD5sK5PtGufxCrZdrW1zfPjKljMUc1IeqMuffz8karmQK8duP5sAOK9GezkrBOdBKjthC0229+m1g3I4JGw02qvbfXovgSl96EJ36g48Cyvx4HqFnAi5bfW4bvqONxq5WNWaLi173GT2mBL9CuEMxVyPho dWBud5+B meoFmkkSLazn+uRq1xCTb+r4JdbGjyAxKOifAlN9WahKCZB1aSlwG3PA1DXzpKbHus4AJQeS+TxI4WJI/r02S2k/qScvjNtmQCqhKy4A0GEotlTAwZH/iMi1jVjrfXTwoNlVYrxlMYoyjwf+N9LvXfBYsXChmA1b+HIV3YMXwVLwr03d9B+RC+nEB41n4Y3Ck3uB1MkHypm90f/d7lL6Nm7OX0r+t2FdoSLLPI6vxQzQaoSZIY36ccGJndx4U2a4owRnABMifZdEaM1a0nfIHYxofmMERJh1eVQAzixw2n7cMGss= 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 Tue, Jul 15, 2025 at 02:24:38PM +0100, Will Deacon wrote: > Hi Leon, > > On Wed, Jun 25, 2025 at 04:19:05PM +0300, Leon Romanovsky wrote: > > From: Leon Romanovsky > > > > Convert HMM DMA operations from the legacy page-based API to the new > > physical address-based dma_map_phys() and dma_unmap_phys() functions. > > This demonstrates the preferred approach for new code that should use > > physical addresses directly rather than page+offset parameters. > > > > The change replaces dma_map_page() and dma_unmap_page() calls with > > dma_map_phys() and dma_unmap_phys() respectively, using the physical > > address that was already available in the code. This eliminates the > > redundant page-to-physical address conversion and aligns with the > > DMA subsystem's move toward physical address-centric interfaces. > > > > This serves as an example of how new code should be written to leverage > > the more efficient physical address API, which provides cleaner interfaces > > for drivers that already have access to physical addresses. > > I'm struggling a little to see how this is cleaner or more efficient > than the old code. It is not, the main reason for hmm conversion is to show how the API is used. HMM is built around struct page. > > From what I can tell, dma_map_page_attrs() takes a 'struct page *' and > converts it to a physical address using page_to_phys() whilst your new > dma_map_phys() interface takes a physical address and converts it to > a 'struct page *' using phys_to_page(). In both cases, hmm_dma_map_pfn() > still needs the page for other reasons. If anything, existing users of > dma_map_page_attrs() now end up with a redundant page-to-phys-to-page > conversion which hopefully the compiler folds away. > > I'm assuming there's future work which builds on top of the new API > and removes the reliance on 'struct page' entirely, is that right? If > so, it would've been nicer to be clearer about that as, on its own, I'm > not really sure this patch series achieves an awful lot and the > efficiency argument looks quite weak to me. Yes, there is ongoing work, which is built on top of dma_map_phys() API and can't be built without DMA phys. My WIP branch, where I'm using it can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dmabuf-vfio In that branch, we save one phys_to_page conversion in block datapath: block-dma: migrate to dma_map_phys instead of map_page and implement DMABUF exporter for MMIO pages: vfio/pci: Allow MMIO regions to be exported through dma-buf see vfio_pci_dma_buf_map() function. Thanks > > Cheers, > > Will >