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 77967C3600B for ; Thu, 27 Mar 2025 17:57:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36777280113; Thu, 27 Mar 2025 13:57:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 316862800FF; Thu, 27 Mar 2025 13:57:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DE92280113; Thu, 27 Mar 2025 13:57:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 01F5B2800FF for ; Thu, 27 Mar 2025 13:57:01 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 17F691A0312 for ; Thu, 27 Mar 2025 17:57:02 +0000 (UTC) X-FDA: 83268087084.26.09DE159 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf16.hostedemail.com (Postfix) with ESMTP id DB0F1180004 for ; Thu, 27 Mar 2025 17:56:59 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=AmCJf6ka; dmarc=none; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743098220; 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=e7qhW86gw6ksGrHv917jkoJ0GWbsFORRxJCR5hvi1mw=; b=ZhjcGHFDAPI1HhEAvN1t43SxnaWdoGaqeuXt+oudeP0kFUHoArN6QVNqodunfn0uXnn1wv QpyM8dj+mixijBlmfS8mgoKrSVjHcsinSPpC4O3Btkm41dDbs2F3ZT6g1cVbFcYYvENate Va/DlZ73PARjxrW1l5ZytqdtKWwC01c= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=AmCJf6ka; dmarc=none; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743098220; a=rsa-sha256; cv=none; b=QYdMloydbow/hj4ws8dI5bM8EdTWfUesTwynKuqWgozC+5V5qbl7OfSQdWxZCz/DWSYNiP cM/U2Zocdj20fajzTa6uiY9Z57YaIvMMDVPKN0HkrjVJDQd/hf6rVOBs6lPbRKPJ/HHjAV pzpM0JUWlPrnA+35DAvv2amPgxgYu0I= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=e7qhW86gw6ksGrHv917jkoJ0GWbsFORRxJCR5hvi1mw=; b=AmCJf6kahzOBXmlRcZU8wcX3UF vmpXttqhE88Uw9luLugvLY8ttEAe3Qrdn/hrMNYj1RpQrsF+oakUI7Cd3NAYtbi8bVOxVO7VF+pba OygCb1bDerYbCdHAEuH9l3HNniJ5IjxjEqEyOV++P1P2pESA00mnNENWicqltuP/mcd+9rVC60uWk WAXxKcEQL66uC31I2kut7Ui8EdyOvI8TmSbdySN8Qy/5Ndm5pQcV7UEw0NaBa6acY6rFLUmrc2SNw QjEzkFN7uacSjs9MLeTdSwAHAerZ7cznOYlNPS8hVZKhbuUaB0Vvk/3YEdUBeCgRHT3M8IjUyuna/ vxJ0avNw==; Received: from willy by casper.infradead.org with local (Exim 4.98.1 #2 (Red Hat Linux)) id 1txrSi-0000000FIF4-1ITi; Thu, 27 Mar 2025 17:56:16 +0000 Date: Thu, 27 Mar 2025 17:56:16 +0000 From: Matthew Wilcox To: Robin Murphy Cc: Leon Romanovsky , Christoph Hellwig , Jason Gunthorpe , Jens Axboe , Joerg Roedel , Will Deacon , Sagi Grimberg , Keith Busch , Bjorn Helgaas , Logan Gunthorpe , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , Marek Szyprowski , =?iso-8859-1?B?Suly9G1l?= Glisse , Andrew Morton , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-rdma@vger.kernel.org, iommu@lists.linux.dev, linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, Randy Dunlap Subject: Re: [PATCH v7 00/17] Provide a new two step DMA mapping API Message-ID: References: <20250220124827.GR53094@unreal> <1166a5f5-23cc-4cce-ba40-5e10ad2606de@arm.com> <20250302085717.GO53094@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: DB0F1180004 X-Stat-Signature: q7gbauekmeebin4wqbo7f8oreifr51c3 X-Rspam-User: X-HE-Tag: 1743098219-162455 X-HE-Meta: U2FsdGVkX18yEKt19rSmtTpBTvQzHutbFYXtWDX5wJllegGVYWycIeJWAkJ+rDcaYgoFCMAVS8h9UlemBYy8N4BUt2jxsbJ+e6OXcFVM6i1SZi/yL0MbC3Y82foEj0IM9X+ChaxD/6VzODRLjXGKtvzLlFd5FBe+spAZhy/vpcnJGfGuPvOdNG7JtznMBGJIXMpZSOwoYmAdwYd7GdL25pv+BNlUGY34txmmQbzNf0/6GJ+mB/CrIUeEv6JZKdLb4wybzuZzjJXwnoPoB5sradr/QohKPyVqt/yINBgXI9VhuH1s1jWKD6OrDgt5+v6j6FgsCCn6rkmjP7EVXjwUjbzKGoNTmYU2UvKoamb7DtkhK7qF/VyHl6Us8w34jpis5tKvI7/ZYIDpUMEC4/2GJXaOyGY4fQfQJr4CiZs6Vjf2l87mxEfAZTaGR/Lioom/x5BLrW6ZWAgV/Dgg4GcsZXMIqX49Yem2oTsksneMRr3q4/271IopG3EzywZwlnJT1o7Jw91VVZMLOZDspJln8kRFbz9azUkMPXiDNrWrZHi3+MF0jb3CulJq++6yY6gYYpPJpG3jeOn1JF/tt5u7BIuzh7774Y9mR7yKd+Q4XELZpSyFkgcVGwihno28zdiFTBHoYg/vx13X/AagBjoDz27UmFyjyy3pUjINEvXTAMdh9tzlo9Tmfy4Na6oUnhqEC03kWApB9pHkEdewBQj3WjAk/wYRCkkw4zNj6yilZ8cDcxilxPzK2mD7h8obcWTK5b9AiBlMgZGF5Aq9RL/6kaibqYFdiVIQM5xeR5PSM2PfW8uP8mNOCqJJ4n9Hl5k/6UBj93ZZbZxX7AINrkwMZdx2gKyFTr8ysznwK/9NWeVjVNXDeYFGTgnfwtdcf/+DvgY7dvJZjYE9o7MBd6oNS2yRt5CZoxmW3e8cyevPv+CW5qWPPbsdQ+gDyDMMIBpkm8gRMCjC0iwcZq0jV/c gy4L3yqp m78v3vT2+8oWM83pe/anVWjDqy2Qw9flUZfK1zXgq2J59q1gEuf5Ss1rH9v/BUZ5GS46xxRvbHvLokTDa9nFPqG1mr0fD431l8sCiJepaDirT+/4JT49+u7AjWFrsfRcCjlJ/2bmILm/TiUlzp4LGqaBdh5rXRbbZf7w8RbsWnBgVrAhxy0+V0DrOoXTOvVxNkbXK0Aqd3mTBI+Qum+3+qkjZ5g/9Htmv/TEgfWOYTOeTk0g= 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, Mar 21, 2025 at 04:05:22PM +0000, Robin Murphy wrote: > > The main issue which we are trying to solve "abuse of SG lists for > > things without struct page", is not going to disappear by itself. > > What everyone seems to have missed is that while it is technically true that > the streaming DMA API doesn't need a literal struct page, it still very much > depends on something which having a struct page makes it sufficiently safe > to assume: that what it's being given is valid kernel memory that it can do > things like phys_to_virt() or kmap_atomic() on. A completely generic DMA > mapping API which could do the right thing for any old PFN on any system > would be a very hard thing to achieve, and I suspect even harder to do > efficiently. And pushing the complexity into every caller to encourage and > normalise drivers calling virt_to_phys() all over (_so_ many bugs there...) > and pass magic flags to influence internal behaviour of the API > implementation clearly isn't scalable. Don't think I haven't seen the other > thread where Christian had the same concern that this "sounds like an > absolutely horrible design." Doing I/O to memory which does not have a struct page is the whole point of this series (and many many more patches to come in the future). This is very useful functionality to have. Xen can do it, which is advantageous for a hypervisor as it really doesn't use the struct page for anything; that memory is assigned to the guest and the host only needs the page in order to do I/O on belaf of the guest. I first came up against this problem with the 3DXP project, which is now dead but there are other similar projects that involve giving each machine in a cluster access to a large amount of shared memory, and there's not really a good place to allocate the memmap from. And the only reason to allocate memmap is so that we can do I/O to this memory. I'm sure there are other use cases. Given that nVidia are so interested in this, I would guess that at least one of them involves a graphics card. I don't think that phys_to_virt() is something that has ever been guaranteed to work (HIGHEMEM and so on). I do think that we should support kmap_local_phys() for these things -- there's no need to have a struct page for that. I haven't looked at the implementation, but I think we need to agree that this is useful functionality to have, or this isn't going anywhere.