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 62C14C54798 for ; Tue, 5 Mar 2024 12:05:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB671940017; Tue, 5 Mar 2024 07:05:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A678B940007; Tue, 5 Mar 2024 07:05:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 906FA940017; Tue, 5 Mar 2024 07:05:35 -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 7CC6A940007 for ; Tue, 5 Mar 2024 07:05:35 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3E1CE1C0027 for ; Tue, 5 Mar 2024 12:05:35 +0000 (UTC) X-FDA: 81862855830.08.32B1C21 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf28.hostedemail.com (Postfix) with ESMTP id 5299DC0015 for ; Tue, 5 Mar 2024 12:05:33 +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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709640333; a=rsa-sha256; cv=none; b=mmglB/UDV4ooqR9E7ol4YLyFVwZINvH2lqc/jYRKqidcoJqJowL/i8jDDHIQAdocPAZfWl ZCCB60d4MV2/8GxLlZMx6xO4TI7Xe6u5yTBgH0In2FbG7helbE7njGSqqWp5yrGvZA8ude Z+VWJ565AvEcEUjhfqWwBS1XMAScIrk= 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709640333; 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=Rqswi7ipIoZG+INOG3X2gMd6ini0syHXXW75E+5+5wU=; b=XVy6tofLOt37IFWxUot4OQB9KTOJs9WHOZGEQGdHNgSEZPZyq+agvqfWfBHZZmuJ6Zp2Qw T8C73PUsQWEDvXQQR/hMniRAAh6+W5eWNO4wRTD81lKVXFvl5ZguLvzwVVHfP+bx9VqWNA NbkYP9jWxFAgdBkS9gSSPUyC/1XdQBw= 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 A49DE1FB; Tue, 5 Mar 2024 04:06:08 -0800 (PST) Received: from [10.57.67.228] (unknown [10.57.67.228]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 25B763F73F; Tue, 5 Mar 2024 04:05:25 -0800 (PST) Message-ID: <47afacda-3023-4eb7-b227-5f725c3187c2@arm.com> Date: Tue, 5 Mar 2024 12:05:23 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC RESEND 00/16] Split IOMMU DMA mapping operation to two steps To: Leon Romanovsky , Christoph Hellwig , Marek Szyprowski , Joerg Roedel , Will Deacon , Jason Gunthorpe , Chaitanya Kulkarni Cc: Jonathan Corbet , Jens Axboe , Keith Busch , Sagi Grimberg , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Andrew Morton , 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, kvm@vger.kernel.org, linux-mm@kvack.org, Bart Van Assche , Damien Le Moal , Amir Goldstein , "josef@toxicpanda.com" , "Martin K. Petersen" , "daniel@iogearbox.net" , Dan Williams , "jack@suse.com" , Leon Romanovsky , Zhu Yanjun References: From: Robin Murphy Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5299DC0015 X-Stat-Signature: ya6po95esowtt1pjp8cbwfi15r6ot5h7 X-Rspam-User: X-HE-Tag: 1709640333-984565 X-HE-Meta: U2FsdGVkX1/3Y7SDsAQ97tAp9ft200ubZ7QfCrgKYd9cLVmIda9YJE8Pw6TRP7YGZb8GYWcaBEQ3qQPY4byRqTTwN3Qsih5mPAu0dA3tBQnDBV3h+oybMecQeoh7pa3yqGapVrGmoRZLKK6gdW9uLyTDbHf2ua7PgRyauPgtqLYaZA+QiEUaT4QI5+Y3IVFtXTKNdF0tR9RBuPoagYmdmcEGHEOm9Ltnq2WNxE5J8xYMzdN20hF6Jx1Duycwc8QbjyoFtk48kqM4csmm9sGHXMSD+MFiE5MAfWWGQUXnyNKbEnc3XD1ZGljkGaDRxY1SYj2Y8eYlLlIvzlV4kH5WI/9/GU6yylDVwFXnPpqJ3c0SWaaMa2UiHLCGJlVhrMI+vqeTGDk4PzATvBxsXptzmNXNDQKGg74fbmHG3R1epJgemzaY4h+Arhz+qzokj5LSyTq/HimXMRbudcdIUIyL5jbLEdyxBQ043vy4E8ib4vi1d0zyegg2NCNPilVHDmiEFiUyeLEABGFt68hDxAEjBlnoP0sBqRCb97jY3TbIWeDAurPI5cNQAMnzrtAw+nG743IM0wro9XfKHdyXJo8pZtFwmrNWlSMugWXcCXRPRSiMFmQVTmJ5XRVVzgdEE59xXBqkhpiHNgtpU7yMbR3Ff+vNczAbzasSuLpcibaOqMTK9q3llYAUtwyDhStuu2vXMzrXZOGdyM5nt1doppLE6WzwgWHwzgJNLNcS9d8JyXfTqpJ72cBU/L+uw05FSnnxc4057B4DED85XwktWXSn6ALFrErPgpgNaEAGCMcRx7FopJwmghFMWvdVlLyBIcjprb4NeCjE4f7IpSOkdag/Dpg7CgS1RojPsWbOYXLfL0q6CXRsvOWErePnbNZ8n0CnYcoUZ9YJuY0= 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 2024-03-05 11:18 am, Leon Romanovsky wrote: > This is complimentary part to the proposed LSF/MM topic. > https://lore.kernel.org/linux-rdma/22df55f8-cf64-4aa8-8c0b-b556c867b926@linux.dev/T/#m85672c860539fdbbc8fe0f5ccabdc05b40269057 > > This is posted as RFC to get a feedback on proposed split, but RDMA, VFIO and > DMA patches are ready for review and inclusion, the NVMe patches are still in > progress as they require agreement on API first. > > Thanks > > ------------------------------------------------------------------------------- > The DMA mapping operation performs two steps at one same time: allocates > IOVA space and actually maps DMA pages to that space. This one shot > operation works perfectly for non-complex scenarios, where callers use > that DMA API in control path when they setup hardware. > > However in more complex scenarios, when DMA mapping is needed in data > path and especially when some sort of specific datatype is involved, > such one shot approach has its drawbacks. > > That approach pushes developers to introduce new DMA APIs for specific > datatype. For example existing scatter-gather mapping functions, or > latest Chuck's RFC series to add biovec related DMA mapping [1] and > probably struct folio will need it too. > > These advanced DMA mapping APIs are needed to calculate IOVA size to > allocate it as one chunk and some sort of offset calculations to know > which part of IOVA to map. I don't follow this part at all - at *some* point, something must know a range of memory addresses involved in a DMA transfer, so that's where it should map that range for DMA. Even in a badly-designed system where the point it's most practical to make the mapping is further out and only knows that DMA will touch some subset of a buffer, but doesn't know exactly what subset yet, you'd usually just map the whole buffer. I don't see why the DMA API would ever need to know about anything other than pages/PFNs and dma_addr_ts (yes, it does also accept them being wrapped together in scatterlists; yes, scatterlists are awful and it would be nice to replace them with a better general DMA descriptor; that is a whole other subject of its own). > Instead of teaching DMA to know these specific datatypes, let's separate > existing DMA mapping routine to two steps and give an option to advanced > callers (subsystems) perform all calculations internally in advance and > map pages later when it is needed. From a brief look, this is clearly an awkward reinvention of the IOMMU API. If IOMMU-aware drivers/subsystems want to explicitly manage IOMMU address spaces then they can and should use the IOMMU API. Perhaps there's room for some quality-of-life additions to the IOMMU API to help with common usage patterns, but the generic DMA mapping API is absolutely not the place for it. Thanks, Robin. > In this series, three users are converted and each of such conversion > presents different positive gain: > 1. RDMA simplifies and speeds up its pagefault handling for > on-demand-paging (ODP) mode. > 2. VFIO PCI live migration code saves huge chunk of memory. > 3. NVMe PCI avoids intermediate SG table manipulation and operates > directly on BIOs. > > Thanks > > [1] https://lore.kernel.org/all/169772852492.5232.17148564580779995849.stgit@klimt.1015granger.net > > Chaitanya Kulkarni (2): > block: add dma_link_range() based API > nvme-pci: use blk_rq_dma_map() for NVMe SGL > > Leon Romanovsky (14): > mm/hmm: let users to tag specific PFNs > dma-mapping: provide an interface to allocate IOVA > dma-mapping: provide callbacks to link/unlink pages to specific IOVA > iommu/dma: Provide an interface to allow preallocate IOVA > iommu/dma: Prepare map/unmap page functions to receive IOVA > iommu/dma: Implement link/unlink page callbacks > RDMA/umem: Preallocate and cache IOVA for UMEM ODP > RDMA/umem: Store ODP access mask information in PFN > RDMA/core: Separate DMA mapping to caching IOVA and page linkage > RDMA/umem: Prevent UMEM ODP creation with SWIOTLB > vfio/mlx5: Explicitly use number of pages instead of allocated length > vfio/mlx5: Rewrite create mkey flow to allow better code reuse > vfio/mlx5: Explicitly store page list > vfio/mlx5: Convert vfio to use DMA link API > > Documentation/core-api/dma-attributes.rst | 7 + > block/blk-merge.c | 156 ++++++++++++++ > drivers/infiniband/core/umem_odp.c | 219 +++++++------------ > drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + > drivers/infiniband/hw/mlx5/odp.c | 59 +++-- > drivers/iommu/dma-iommu.c | 129 ++++++++--- > drivers/nvme/host/pci.c | 220 +++++-------------- > drivers/vfio/pci/mlx5/cmd.c | 252 ++++++++++++---------- > drivers/vfio/pci/mlx5/cmd.h | 22 +- > drivers/vfio/pci/mlx5/main.c | 136 +++++------- > include/linux/blk-mq.h | 9 + > include/linux/dma-map-ops.h | 13 ++ > include/linux/dma-mapping.h | 39 ++++ > include/linux/hmm.h | 3 + > include/rdma/ib_umem_odp.h | 22 +- > include/rdma/ib_verbs.h | 54 +++++ > kernel/dma/debug.h | 2 + > kernel/dma/direct.h | 7 +- > kernel/dma/mapping.c | 91 ++++++++ > mm/hmm.c | 34 +-- > 20 files changed, 870 insertions(+), 605 deletions(-) >