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 DAF98C282C6 for ; Fri, 28 Feb 2025 19:54:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EBB26B007B; Fri, 28 Feb 2025 14:54:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 699EB6B0085; Fri, 28 Feb 2025 14:54:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58896280001; Fri, 28 Feb 2025 14:54:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3C1656B007B for ; Fri, 28 Feb 2025 14:54:20 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EEC0C1A1231 for ; Fri, 28 Feb 2025 19:54:19 +0000 (UTC) X-FDA: 83170405038.27.99D5303 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf28.hostedemail.com (Postfix) with ESMTP id 06F29C0005 for ; Fri, 28 Feb 2025 19:54:17 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf28.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740772458; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HJ1Nq4pcXXodfLNoK+SRpDDH/JY0EL7hd7uzSX9UuYU=; b=btKlOrvkpHGW7ZyYVyJE1uAV3AYhvOLAFdsEbLNmjve3W/aymh6cf1fGyRyYzUJYxIH42O V2y47EQj9DQ7Q1muup2wpo46Vu8D/zc15mcytm9ESMSDnUN3h3LlnYjTbdcQ5QVvWdvrpA OEG8PwsdPVazETQxVPDTllygagN1y0o= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf28.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740772458; a=rsa-sha256; cv=none; b=3IhG5XRtXWg11z9W4KkrmB0pM0RfyZ/DKidnjtb8nMNmYVnrFHC61eaQUwuV/rVoTKy666 K4Zrp+vSG+L1ZTaPWShnWl1Ss1qOKrfXa6vWwbSjwVVhhrTPGp9GvMrB8DdodeHgZ0kwBq InEOaiXjYFntmhzDffeg1JvDt3qt8qc= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1DD0F150C; Fri, 28 Feb 2025 11:54:32 -0800 (PST) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 53B2F3F7D8; Fri, 28 Feb 2025 11:54:13 -0800 (PST) Message-ID: <1166a5f5-23cc-4cce-ba40-5e10ad2606de@arm.com> Date: Fri, 28 Feb 2025 19:54:11 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 00/17] Provide a new two step DMA mapping API To: Leon Romanovsky , Christoph Hellwig , Jason Gunthorpe Cc: Jens Axboe , Joerg Roedel , Will Deacon , Sagi Grimberg , Keith Busch , Bjorn Helgaas , Logan Gunthorpe , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , Marek Szyprowski , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , 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 References: <20250220124827.GR53094@unreal> From: Robin Murphy Content-Language: en-GB In-Reply-To: <20250220124827.GR53094@unreal> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: sqqk8es4d3ek1tt9n3u6mtqtf6aqy9dt X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 06F29C0005 X-Rspam-User: X-HE-Tag: 1740772457-552 X-HE-Meta: U2FsdGVkX1/SRQLED5uT0SIuq3GKTpurX57HD0vj+em3yXZyZJWP8igL3PBBZKViYDf9HQQiX0zcLHYBSAaeSr0I2LZ4pRUMX1U123L+ug6esn/shqS47EsmwzCeakw29tJYNUt6BnvGw7c5ahoYdj7Gm3aWMrD3iz8oNx+zoo0aBnUSa5o/w3FlMwc82WNLWuoyH968Kx2SK3Jh1M3TC+MbZU5HuYubTfZpyH/+VoKErY+2H50cU/0jPqXN5vpZcLLUKMHsCJAHOuUsDZGzCCzej6XtSa5+l+Pq+D8NXBwjRkVUhi83Nsncah2664V9NUIFRguCuNLrr5l1+597B51vsJkvEOUwwuYTjRySxV1TftYtvRbKx9Y1DrPePHqdS2N00LwmduIGHHhQvKKQwtgN5TWNX1PDzAdoLSLxJLbmTuMVg7bskWJxrlhBI179Tqg0TNQZb/DOEl4FkFEcGd+Ws/2CUnOAd7QWsE+8Qf3jvRP4C45KnE+TLs9ndcL6LK+srdgRgwD/3UtROYW4Az50UkoFcma+Q+EG03VD8qedTcDnUuAurcvPEhKwbZ/7e9fn2ICZ9jgLnVYUhRSA7GDEyuT93IRQBhKm1bfsaL3UQ+hmlkhRZBig7qqoTCykeQhz2Jv4o+HCqz62zILOWRR787Zl0x0mhdDbFgECdc3T0GeYGfYG/6Ulhk0yJEqTFBcndh138j7Qk+yOVmpiDqM6kvznCs3E2xyYwCwaQ8ix6K8tWovle53simRrjUTOvb/fSU4wRkqVhTmc8kQlXCACD+mzYV+HgWDyoEn0hsOWGI7bt46KfUOwhzJuvMIqboaClt4ZQ3FpMfvky6k2IYNRBEcicS9c3XjkIi0nAu0FFFZ2Q2kDPDL/N9XIey6jDfa64b6dJWcnRccb5/Z8NLD4vnqzuo5qrVZ1e73bD8eHGkhlI+bHPlgP1GvFF3NdOlqVftBBL9eGIcRj5pe HE0pX9f0 btxLa+q2Z8gaP7XWF0qqOjeadKJo7eHGcTCRxFtzE1P6DjcDbyX0SucV/Ul1ohfKMKEKhPo9zdvhwI0t9wp/aLzJpXvlKncidWhnvALvCSfY2B+aQvSSl2pcJfM7zLd3IVCd2MVTP3g5eFlFOyZcRfMmeSSlUeddYKutuLO2zUE7VG2o= 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 20/02/2025 12:48 pm, Leon Romanovsky wrote: > On Wed, Feb 05, 2025 at 04:40:20PM +0200, Leon Romanovsky wrote: >> From: Leon Romanovsky >> >> Changelog: >> v7: >> * Rebased to v6.14-rc1 > > <...> > >> Christoph Hellwig (6): >> PCI/P2PDMA: Refactor the p2pdma mapping helpers >> dma-mapping: move the PCI P2PDMA mapping helpers to pci-p2pdma.h >> iommu: generalize the batched sync after map interface >> iommu/dma: Factor out a iommu_dma_map_swiotlb helper >> dma-mapping: add a dma_need_unmap helper >> docs: core-api: document the IOVA-based API >> >> Leon Romanovsky (11): >> iommu: add kernel-doc for iommu_unmap and iommu_unmap_fast >> dma-mapping: Provide an interface to allow allocate IOVA >> dma-mapping: Implement link/unlink ranges API >> mm/hmm: let users to tag specific PFN with DMA mapped bit >> mm/hmm: provide generic DMA managing logic >> RDMA/umem: Store ODP access mask information in PFN >> RDMA/core: Convert UMEM ODP DMA mapping to caching IOVA and page >> linkage >> RDMA/umem: Separate implicit ODP initialization from explicit ODP >> vfio/mlx5: Explicitly use number of pages instead of allocated length >> vfio/mlx5: Rewrite create mkey flow to allow better code reuse >> vfio/mlx5: Enable the DMA link API >> >> Documentation/core-api/dma-api.rst | 70 ++++ > drivers/infiniband/core/umem_odp.c | 250 +++++--------- >> drivers/infiniband/hw/mlx5/mlx5_ib.h | 12 +- >> drivers/infiniband/hw/mlx5/odp.c | 65 ++-- >> drivers/infiniband/hw/mlx5/umr.c | 12 +- >> drivers/iommu/dma-iommu.c | 468 +++++++++++++++++++++++---- >> drivers/iommu/iommu.c | 84 ++--- >> drivers/pci/p2pdma.c | 38 +-- >> drivers/vfio/pci/mlx5/cmd.c | 375 +++++++++++---------- >> drivers/vfio/pci/mlx5/cmd.h | 35 +- >> drivers/vfio/pci/mlx5/main.c | 87 +++-- >> include/linux/dma-map-ops.h | 54 ---- >> include/linux/dma-mapping.h | 85 +++++ >> include/linux/hmm-dma.h | 33 ++ >> include/linux/hmm.h | 21 ++ >> include/linux/iommu.h | 4 + >> include/linux/pci-p2pdma.h | 84 +++++ >> include/rdma/ib_umem_odp.h | 25 +- >> kernel/dma/direct.c | 44 +-- >> kernel/dma/mapping.c | 18 ++ >> mm/hmm.c | 264 +++++++++++++-- >> 21 files changed, 1435 insertions(+), 693 deletions(-) >> create mode 100644 include/linux/hmm-dma.h > > Kind reminder. ...that you've simply reposted the same thing again? Without doing anything to address the bugs, inconsistencies, fundamental design flaws in claiming to be something it cannot possibly be, the egregious abuse of DMA_ATTR_SKIP_CPU_SYNC proudly highlighting how unfit-for-purpose the most basic part of the whole idea is, nor *still* the complete lack of any demonstrable justification of how callers who supposedly can't use the IOMMU API actually benefit from adding all the complexity of using the IOMMU API in a hat but also still the streaming DMA API as well? Yeah, consider me reminded. In case I need to make it any more explicit, NAK to this not-generic not-DMA-mapping API, until you can come up with either something which *can* actually work in any kind of vaguely generic manner as claimed, or instead settle on a reasonable special-case solution for justifiable special cases. Bikeshedding and rebasing through half a dozen versions, while ignoring fundamental issues I've been pointing out from the very beginning, has not somehow magically made this series mature and acceptable to merge. Honestly, given certain other scenarios we may also end up having to deal with, if by the time everything broken is taken away, it were to end up stripped all the way back to something well-reasoned like: "Some drivers want more control of their DMA buffer layout than the general-purpose IOVA allocator is able to provide though the DMA mapping APIs, but also would rather not have to deal with managing an entire IOMMU domain and address space, making MSIs work, etc. Expose iommu_dma_alloc_iova() and some trivial IOMMU API wrappers to allow drivers of coherent devices to claim regions of the default domain wherein they can manage their own mappings directly." ...I wouldn't necessarily disagree. Thanks, Robin.