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 058E9C28B28 for ; Wed, 12 Mar 2025 09:28:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62E5F280002; Wed, 12 Mar 2025 05:28:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B88C280001; Wed, 12 Mar 2025 05:28:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 40C9D280002; Wed, 12 Mar 2025 05:28:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1EF47280001 for ; Wed, 12 Mar 2025 05:28:42 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CF4F5B7C99 for ; Wed, 12 Mar 2025 09:28:42 +0000 (UTC) X-FDA: 83212374084.27.F349F50 Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by imf25.hostedemail.com (Postfix) with ESMTP id 1A108A0005 for ; Wed, 12 Mar 2025 09:28:39 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=Ze2jFdmu; spf=pass (imf25.hostedemail.com: domain of m.szyprowski@samsung.com designates 210.118.77.12 as permitted sender) smtp.mailfrom=m.szyprowski@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741771720; 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:dkim-signature; bh=jM2XikXEr0ikBo0oLtomrsxm7QlhoeG8uKeeSTS19yM=; b=WDnFmkCzbtVeF+kFarKO3kNDUkwiPDlJWKqzv4a2C34fuF9Fats36pVxVinWWTZDp9D/bi +AxCYSGG3j5LT2uLkjD0VS72ee4T7pJKbkIjw+MBgFBntWwlWDC0C84u9zotmbP1fMzbOV IDdLsZSZ/ohj5mQdnvQ+QxbU1ubFic0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741771720; a=rsa-sha256; cv=none; b=bBLsoSQoiKDiAvB1X/3KSP/orFruQDDRSobz26OifJOxhq1Y7a/2+3w6Y0Bqxf6PH5kW4R S9X92ClaNpzOfugCVGPHIa0zLm4d4Eg6xatrvrsV08eB0E5baJCXbpNCQrp/djSqcEvVyg lBzndSgH/1sh1zzp8l2gfVcRCC878DA= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=Ze2jFdmu; spf=pass (imf25.hostedemail.com: domain of m.szyprowski@samsung.com designates 210.118.77.12 as permitted sender) smtp.mailfrom=m.szyprowski@samsung.com; dmarc=pass (policy=none) header.from=samsung.com Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20250312092838euoutp02c8aa3d1e309697e7cf40026db38d3509~sBCY2FPyX1238912389euoutp02N for ; Wed, 12 Mar 2025 09:28:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20250312092838euoutp02c8aa3d1e309697e7cf40026db38d3509~sBCY2FPyX1238912389euoutp02N DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1741771718; bh=jM2XikXEr0ikBo0oLtomrsxm7QlhoeG8uKeeSTS19yM=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=Ze2jFdmuO0cLLYqLIJd51/wQzBFKAzxgIHozoFZZoNuFZcFG485swGkdKMqUW/Zvp cl2zr4/04Ndda/wzPd5iBES/LxTo9/80XTM5/yJ6P9bBGWVcJ9B29HLYT+lSWshREK 7AGTFVkE3KSlN6ONOEzzV8Pi8Yif9QuOagwPNUks= Received: from eusmges2new.samsung.com (unknown [203.254.199.244]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20250312092837eucas1p25b1b9a0eaeeeb28386900bd5799beff7~sBCYkpiud1062910629eucas1p2o; Wed, 12 Mar 2025 09:28:37 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges2new.samsung.com (EUCPMTA) with SMTP id 6E.F9.20409.5C351D76; Wed, 12 Mar 2025 09:28:37 +0000 (GMT) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20250312092837eucas1p141720d6a0df85c410f2b2209e4cb4ae1~sBCYE1szl1182811828eucas1p1t; Wed, 12 Mar 2025 09:28:37 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20250312092837eusmtrp1bf90383d9f98004fe39bcc48be1d1fe1~sBCYCvohl2987729877eusmtrp1N; Wed, 12 Mar 2025 09:28:37 +0000 (GMT) X-AuditID: cbfec7f4-c39fa70000004fb9-67-67d153c532b4 Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id 8C.F0.19654.5C351D76; Wed, 12 Mar 2025 09:28:37 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20250312092833eusmtip25e36488a2aac248bc9b654fb690ddc66~sBCVArikT0743107431eusmtip2e; Wed, 12 Mar 2025 09:28:33 +0000 (GMT) Message-ID: Date: Wed, 12 Mar 2025 10:28:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 00/17] Provide a new two step DMA mapping API To: Robin Murphy , 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 , =?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 Content-Language: en-US From: Marek Szyprowski In-Reply-To: <1166a5f5-23cc-4cce-ba40-5e10ad2606de@arm.com> Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0xTZxjH97anp6VQdiwobxRH2l2o6KigZO+CdgyNOfpBXbbswz64NeNY CBehpWzMLDYMtHRctEiAgoDaCqNFsIxuVlHbgS0QBsiYchGDKZVLymgHTmGbkx628e33f97/ c83LYfLb8c2clIxsSp4hTRPiXMxy93n/210fDsp23l+IRDUtJhw9fVGEI+PDUhzp85KR684Z gL4zdjHQ8iJCVZVOgKorphmosLqVjbT2XwEyeNrZqKY8C51fNjBRx+h2dPG0HkND1hocTZhe sFDdlSk26qt14MhtL8aQvuAlecYrMGRbcLHQ1bnfMPTDcB4L5Y/HoSvl3IRw0mWrZZCmWhMg 3cNuQNablWT/xDWMzO/0sMi2xijy8s0ZBjnUpyTNTYU4afZp2aSzcgUj2/SnyOm2KkDeGFHh 5OWSMtbR0E+4e5KotJQcSi6WfMZNHnFuybwt/rLQ7mCoQEOkBnA4kNgNB31JGsDl8IlGAN13 F1i0WARw5vwyoMXvAHYUexkaEODPaLSq11wNAN6ssmO08ALou9eMrbp4hATeLzH5MzDiTVg8 1bEW3wC7q1x+3khEwEejlexVDiH2wzuWc8zVQqFEEYC2oT/9JibRg8PnTw7QHAZHXXX+ojgR AzUeDb7KAUQ8nC/4hU17IuA37dX+QpCwceEDSyWLnns/tBuMaxwCZx3fs2kOh71lRRidcAbA +pVHDFqcBVD1ZBTQrng4/vMyvnozJrENtljFdPh9OLA0yaZPGQwfeDbQQwRDraWCSYd5UH2a T7vfgjrH1f/a2gbuMc8CoW7dXXTr1tStW0f3f996gDWBMEqpSJdRitgM6otohTRdocyQRX9+ It0MXv7s3r8diz+ChllvtB0wOMAOIIcpDOUZ9w7I+Lwkae5XlPzEp3JlGqWwgy0cTBjGu3S7 QMYnZNJsKpWiMin5v68MTsBmFePjg7uDJLceL73TCqhcgSZ3LKG6YW5raimP79tbJ7IOPhN9 HSw0fNsaNBU73xqi8mZH5R3ftz0oueX68eFbG6mTzUWmngZkbntNqy4XRbD7+1KOxM2ee336 5A1nwS4ROcuO73Ad3PNXafjAoLUvzM2aCzarX+lWR838NB75kbDp6OTY4WMRIx/scqDCkmvR mRZfzAF9iWfb4USxTLyvbjgywfB4x3sGZ41AkihauhCYmHr9VEp1z8oxmVv4blpvVhzPc8im FVyaP2T7Y6458NmwoF/wVCu52J3onUh/WLcjMKdr2rh10TDQOPZqIRmeuSmrPj9TH7up842y nCM7JztJIaZIlsZEMeUK6T9oYz5PSAQAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJKsWRmVeSWpSXmKPExsVy+t/xe7pHgy+mGxybwmoxZ/0aNotv/3vY LFbf7WezWNKUYfHkQDujxcrVR5ksfn2xsJg54wSjxezpL5gsOmdvYLeYdOgao8XSt1vZLeZM LbSY8msps8XeW9oWC9uWsFhc3jWHzeLemv+sFvOXPWW3ODvvOJvFs0O9LBZLWoGst3ems1gc /PCE1WLd6/csFtuvNrFatNwxtVg2lctBxuPJwXlMHmvmrWH0eHb1GaPHgk2lHufvbWTxaDny ltVj8wotj8V7XjJ5XD5b6rFpVSebx6ZPk9g9Tsz4zeKxeUm9x4vNMxk9dt9sYPNY3DeZNUAk Ss+mKL+0JFUhI7+4xFYp2tDCSM/Q0kLPyMRSz9DYPNbKyFRJ384mJTUnsyy1SN8uQS/j5gnp gv36FZ2HjjM1MC5X72Lk5JAQMJFYsauDtYuRi0NIYCmjxIS/p5ghEjISJ6c1sELYwhJ/rnWx QRS9Z5RY++UkO0iCV8BO4nrfGiYQm0VAVaL36V4WiLigxMmZT8BsUQF5ifu3ZoDVCwu4SBzY NpEZZJCIQA+jxLdTrxlBHGaBM2wSl08dZodYcZtR4u6OZ2DtzALiEreezAdbwSZgKNH1FuQO Tg5OAWuJd61X2CFqzCS6tnYxQtjyEs1bZzNPYBSaheSSWUhGzULSMgtJywJGllWMIqmlxbnp ucVGesWJucWleel6yfm5mxiBaWrbsZ9bdjCufPVR7xAjEwfjIUYJDmYlEd7VthfShXhTEiur Uovy44tKc1KLDzGaAoNjIrOUaHI+MFHmlcQbmhmYGpqYWRqYWpoZK4nzsl05nyYkkJ5Ykpqd mlqQWgTTx8TBKdXA5MXweTLfSoUt60qSqyf199psCJmzLOjbt8Dp+7jLF2+ZuEluf1nFmbOd l+qXd9/ft6TgwH4DreD/wnf1z2qZXhOetSktKnbvNVmG5GOnBBm31dzN+6q+VYDH/nXctaXM DRaGhnPUPZ5uLq/ju9p/c8Lyk3EfPjhwBL4XLv7acvXf23j5OaW87x66Vu0X7fJa8Thh2ccZ gsVbGVZfm5p4ViVl+65LbPukf8vc5kivmOKxdG+f8RpZ3sqDYcteLtZunVmxxVM+7JHComdz /OTe5AR/tP1X1fZmt+BTkYmPJr/2fLbOLX6/YIXdFHGLCU2v7nSZ83W9mB+3dPf3mvIjtrN5 81IPXWh+2M93O+XnxA4lluKMREMt5qLiRABwmQ+33AMAAA== X-CMS-MailID: 20250312092837eucas1p141720d6a0df85c410f2b2209e4cb4ae1 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20250228195423eucas1p221736d964e9aeb1b055d3ee93a4d2648 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20250228195423eucas1p221736d964e9aeb1b055d3ee93a4d2648 References: <20250220124827.GR53094@unreal> <1166a5f5-23cc-4cce-ba40-5e10ad2606de@arm.com> X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 1A108A0005 X-Stat-Signature: 8tf1pn1bqh43itqcmtrd4b8db7q6w3wf X-HE-Tag: 1741771719-571334 X-HE-Meta: U2FsdGVkX19nXZdOwpFYQrNApzkZ7hV4blK0XHYK9r9FQRkij2vq/M2PGsfzk8o4FHOLg67WMuSUpJoJrm6J/Z600WxDOQC/HkmAbwB42uZo+XW5qxefWIZjwm3/HH19CjE3M7N0me0YYXEza0SNl2HxZAW9i43jSUv+VGowxqLW1N4lNdFeMTmGA/ifVQUacAdvfWe/XNZd+GVl1urs4C5GtY/Lv0wiwrS6WRwE9WxmchE1PRtAtg1r8dLyM6zXaPEc3fDT05gCyp61Pm8swXID4RhLiXue02K5qBo4yNdnJ8aofQ+QTiqgzOcItNe5v2KYldJWDYPMNK85L8G9ujakQiyY0ht/7JF8hIWeMQha74GANYElJx3VL4BWGetp/Vr/QrpFTFukd4cjT94WP4BcoA7NdCMB3kzfqxuAWPZ4eco7/CpAwoTaTUYqwBuD0LzUyewkOP6Tuhwkn7GLyDfydyALT6P+/rJtdoVjHd3M5uYIFajvDWs+c0PAxmFjgAQIcPpp9evQU5HuYXPkR/3PA0Pi/q1dXIkkCbJMvFWgNQr0dNo8V2B2KTnyLi0uF8WUmmOW/l3L7FVY5O5LY3e51+Wr0BDPxkdq0cFdowmkHDETwkejexYUl4T+2Wx+IDzc3a1kPrL6/VWtusJ+uHEisGzYsIcSbUXdC5lrW+y/2s/NTtJ8jJamC34nB31VD3RjpwKm1kIvpHtwIO7hSDAvqQDSwNdMEjGZk3aFJWsCZtZIvVMwqro/hm88RGpu1S6ljiXPYB/IRIh9ZOqWCj8ckgGQcK9ByB/pvvxJdaP+cv3YUqyS3wZYrj3m8zQ+q9inKzjKFFb3959AMAuSOkJlYW9ZsQUBM76bFwTJ24KqduHV9otSjzFrczR7jXhb7jexmQprR5rHXPmgn8lB5mz9AZrhpUfVU7mIUza8Khy4dCqV405PsKn6VorAYKO0Gb8nbVXDm/j93IVmEge eFvNMTvw GSwyL/wPyZUNPkxfEMihvjQd0v0sfq/MwgO/D6OD+BaStWmCcxrl7MK79KVx7zEI2dZHQo/6XsW6aa43jnQ2o+y7s6OQ1883Bz6CLAZy3jujkmwuq83K5T9dpZvYZUhSO6tVN 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: Hi Robin On 28.02.2025 20:54, Robin Murphy wrote: > 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. Well, this is definitely not a review I've expected. I admit that I wasn't involved in this proposal nor the discussion about it and I wasn't able to devote enough time for keeping myself up to date. Now I've tried to read all the required backlog and I must admit that this was quite demanding. If You didn't like this design from the beginning, then please state that early instead of pointing random minor issues in the code. There have been plenty of time to discuss the overall approach if You think it was wrong. What do to now? Removing the need for scatterlists was advertised as the main goal of this new API, but it looks that similar effects can be achieved with just iterating over the pages and calling page-based DMA API directly. Maybe I missed something. I still see some advantages in this DMA API extension, but I would also like to see the clear benefits from introducing it, like perf logs or other benchmark summary. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland