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 E6B44D5AE71 for ; Thu, 7 Nov 2024 08:33:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D5076B008C; Thu, 7 Nov 2024 03:33:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 185636B0096; Thu, 7 Nov 2024 03:33:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04C166B0098; Thu, 7 Nov 2024 03:33:05 -0500 (EST) 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 DC2816B008C for ; Thu, 7 Nov 2024 03:33:05 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 75EF11C4F1B for ; Thu, 7 Nov 2024 08:33:05 +0000 (UTC) X-FDA: 82758632166.13.5139E5B Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf23.hostedemail.com (Postfix) with ESMTP id 792D314000F for ; Thu, 7 Nov 2024 08:32:40 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730968324; a=rsa-sha256; cv=none; b=OE1Q3KRM/EYdcs5r4nSe1FCjTQoMk1d3RsIpalptSk1PUJoCs6Q+krrAOkiU5rIW/NPr2m QaLQzd5WQIkfI1QQC4ftEnxorYQ1e6C8fOHMIJnm4hpuLaguerH/BWxvaszDYiKY4M4cQF dPzx6Qj8i4dm++etNUp9t4dhZnGLMw8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730968324; 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; bh=7VYcQSgARTMWilP+aj3J8qRXLCQdx+VA4mtxRoStmpo=; b=5wAWz5pJE+X9WRfFgRlPic5eSBOpDs9Rm2NFY+sJyuw5051ZYyxHOQz3iI/V8chXWgpP4N wD0gwDHTWd6igiXRJlwQB7KcIfXENgOINmlAQTmfyBIPwhHHR5hCtzHGk+du+c6Zsd/LoY WP8TV+IYmiuKpHS1H786Q+/oAuEVQIw= Received: by verein.lst.de (Postfix, from userid 2407) id B5FAE68AA6; Thu, 7 Nov 2024 09:32:56 +0100 (CET) Date: Thu, 7 Nov 2024 09:32:56 +0100 From: Christoph Hellwig To: Jason Gunthorpe Cc: Christoph Hellwig , Robin Murphy , Leon Romanovsky , 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 Subject: Re: [PATCH v1 00/17] Provide a new two step DMA mapping API Message-ID: <20241107083256.GA9071@lst.de> References: <3567312e-5942-4037-93dc-587f25f0778c@arm.com> <20241104095831.GA28751@lst.de> <20241105195357.GI35848@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241105195357.GI35848@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Queue-Id: 792D314000F X-Rspamd-Server: rspam11 X-Stat-Signature: z5ms4wd765xaz148fnih5txyqgp593hc X-HE-Tag: 1730968360-255979 X-HE-Meta: U2FsdGVkX185VZ4LeOeOu+Uo+ipG9/qpQ5Sfs4WCRT35srgPcOvrJH+a0g+COdbh5bQYOVB0WtYTpuQTedFg1uqoTDhKqawZ3LiJdXdHVtO5/ElqbDFCc6hI5Qv3UMhz/tbfpy2i400njd2zZzUFxrqHi1drehbbHCYbHqNZdDJvcf43LPKtY5sJh/S2ZGs3HLs38TocNAMGtWfUDHruixXMW3hZo5ASnRm8cHg1XenO7N96PKLgliIH861Alhm+Dmoawi1PgcpaM8ONTgMAS+0HVI8JIbiFQdtz7pBAaPbOAEYwec0Zei34Ot9XTRMQDixa1xsAYQUMDS8LFDwEQAZHi3sWRTYtFa1Zmz+c4yknzwqiP9NFaiDPRBg8cj3vq+Nqg/W78EMP2sG95S4DiwxXlOiLbd0A/m08U2yPB2ht9povB/+asP/OJqpcpZooJFlJcyUkOExUcQqCP3qVjNINKQXG2qkYeMujHpAQZwFISBmVJe4UvXuSuk/3lVUJiToBcQ7nEAlxEtFXYI6hKBL51bHeXpk/FqRoy83r/RVZ5FSAFDvZoX1HpXmIH+0RMJXp0tbRgSYyiay6qnUIsLKBVsaVJxOspu8LFSuwqedVeYlozmRY3KHL+RgZF+vELd1wd/LynSq+RfWsrECCvZnz//5k01d44I7FTbKMHDMvT7zmoutzHDf6nrp49ne7jCF4v44aJAsGzF5sijnrJehSAjXxQt5ZRdIs38PRyNPuqXMwmL6kG6GgpPF0l4ZbJURtCxIRw1C6cQXyoUCq9pC7PnmURLQtLvo7sC+cLKBOsv0jPuWltBeoPR8ugP1SQyDwB5d17iEvTEQN7kXH6YcjPMymjPsWQ8JPlU/kh/poiBI4Ff+tDbO/c+D8RT41ZZpdtlmdjJ3OHTpv8FpuC1Yju+rFmzPbnDL8ZRS0T6IPWcCCRqARYvkyC5UxZX+tna5lp2zDZJ8LBjFGaLC gdb8nmTs r1gKIls32DWFAb/K/mmlauWtnM5wwW8+XAh6h0ZxMRRfo+ZxvTdbOtwCOIBhtEuRdRhuofrBv4ebvxFw= 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, Nov 05, 2024 at 03:53:57PM -0400, Jason Gunthorpe wrote: > > Yeah, I don't really get the struct page argument. In fact if we look > > at the nitty-gritty details of dma_map_page it doesn't really need a > > page at all. > > Today, if you want to map a P2P address you must have a struct page, > because page->pgmap is the only source of information on the P2P > topology. > > So the logic is, to get P2P without struct page we need a way to have > all the features of dma_map_sg() but without a mandatory scatterlist > because we cannot remove struct page from scatterlist. Well, that is true but also not the point. The hard part is to find the P2P routing information without the page. After that any physical address based interface will work, including a trivial dma_map_phys. > > At least for the block code we have a nice little core wrapper that is > > very easy to use, and provides a great reduction of memory use and > > allocations. The HMM use case I'll let others talk about. > > I saw the Intel XE team make a complicated integration with the DMA > API that wasn't so good. They were looking at an earlier version of > this and I think the feedback was positive. It should make a big > difference, but we will need to see what they come up and possibly > tweak things. Not even sure what XE is, but do you have a pointer to it? It would really be great if people having DMA problems talked to the dma-mapping and iommu maintaines / list..