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 E07CAD6204E for ; Tue, 19 Nov 2024 09:13:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 546546B0083; Tue, 19 Nov 2024 04:13:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F4D36B0085; Tue, 19 Nov 2024 04:13:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 395E36B0088; Tue, 19 Nov 2024 04:13:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 07ACE6B0083 for ; Tue, 19 Nov 2024 04:13:20 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 428ACACB31 for ; Tue, 19 Nov 2024 09:05:19 +0000 (UTC) X-FDA: 82802259246.26.952EB2D Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf30.hostedemail.com (Postfix) with ESMTP id 17D8880004 for ; Tue, 19 Nov 2024 09:03:42 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Cv5uOTxS; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of will@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732006934; 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=ASOqfqo57q8TAqJHgVqYUCyiuGtomZMg9cwiPig5cWY=; b=MxxbRE7hiwOd6Qc6N7cwDD94uQofGNQ2k3tSs8aiNqAAIIqIHblv8DgXvVdF7t8/sma/eP tE+azHl86hQ7+xGqmI8VQscRDtmz8CdiD2umJGEENc4nBfyo2M70QM6vD35kzoPc/Bedtq zhI/n3AyVvkdCc2DyRizl+0z1nY5hmM= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Cv5uOTxS; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of will@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732006934; a=rsa-sha256; cv=none; b=uYM0QUZdPQ/nu9X1Si4STARfK350jZVUN9B2PC2quF/M3OIsH6iLydmbv07BWxeNYUynsN x21goGL4mBlTIuxaSdrD7UHwWKUZ6wiT6vyIPGjyXgCehDhZPt6DOaFHghEc+1jucdeGP+ 6UhYW9dXJqmO8tvLFV29CPH3PwYj4yc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id F02E8A42747; Tue, 19 Nov 2024 09:03:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76DCDC4CECF; Tue, 19 Nov 2024 09:05:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732007116; bh=qslK9QNzD9RoFr7GVJ7I21Lqy9327g4qXpeTSoTD2Dk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Cv5uOTxSRP/Zlfyx8pwvQYettf0TzHwBftoQg8EWUdvGQSUrhYNTkJaHEMt90mnND dL/Xxm06c7d2j9I8IymnJyGN9CGYF9PZAP+AG1HVBzf8AUcthPJhAd+k/qmq8hUeYV 2S4o5Gr48Y2AiD/EmI3wOWkLt4lpEWH0qz0kux7WL6fE8j+1ET//fwy1xbqVocSpXe Ab5mRo9pg4yNjvuqxi0jb4bhYoSNsM4y2N6QC7+4YGcXRWzqXSt7GwZXmZewEqB/OX /tdIXMaJ71vpUzz+qH2VBsIoFVA4QuLQubJhkLUBybYjH8dErW+BjxCo19oKKYayqc wfHTbIuJlL9Jg== Date: Tue, 19 Nov 2024 09:05:08 +0000 From: Will Deacon To: Leon Romanovsky Cc: Jens Axboe , Jason Gunthorpe , Robin Murphy , Joerg Roedel , Christoph Hellwig , 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 v3 07/17] dma-mapping: Implement link/unlink ranges API Message-ID: <20241119090507.GB28466@willie-the-truck> References: <20241118145929.GB27795@willie-the-truck> <20241118185533.GA24154@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241118185533.GA24154@unreal> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 17D8880004 X-Stat-Signature: 3m97gu1stqnu17xr197a7w7n47od4jod X-Rspam-User: X-HE-Tag: 1732007022-923825 X-HE-Meta: U2FsdGVkX18RSjblIWG2yIdhj39M5PtSPGwu7Lv+i0CQ49MY2RCSwjcwO1A/qXGMwxK+N+OWAaQHhhx//oLGb6Q+/gtE8zpPtTtsSpeOkznybAgGgoS6rDRPMLr88Jkj/sBewn9MhJrRn+4DLQJ+U94Y7oj39KHDI35809PYxRqYL78bKSBJL0Cx4Um8nZsfCAUvpkwfn6rPtUcCNjDSmPtOrKTP/vLg8qrsvi/CbuYVHZZqdIqm/w3h33nGd/WJBOEc8XGhS5KvG/MqRZquA0uXWo9XCAzznSqHZa+1a0SOYrHJGrlFh0UfHcHbxjPw8R6Z8gsdaTHiE1hiz1N2mlRJmhxH14vwAbNJFYc9NwEdvK49eXIk3522MsINRWGNAUSKCRah4R5+yp52GmmbEAvjFVjQenUrXHI+H52DYZVoMUicpBdhV/DPXq0hgVKIJp7Veg8EwSpX3C/XXXdZA3bK4qtYaEtJMscqYuMQRf3s+Va4qa1hUhPIYMduD+X0SuEf8Y9Wy1DcXD2yKkmI/Y7TKjyTub4ZdfYvEwWWE/fdZiAyMpf52coryDMyPhkvybvfXcnosvXhGg6dVm5Yfg0VPg3okdoq7HOeY6r3RRU3n4n86Q4KTr9WqBr9JwDPAmzcnPtGd2P+t6/pTv+sP1D+u4QjgZGmjtsCEzhJPUq7+VMx5K/OiKLaV7Vekeo+BPnkSl36QP6ba7pIYj0NZ90yOIJLY93a13ZqksVsHIcQJQVzNF93gXqNqkmOXBTvjMiFHOWrYL+8xrMnHN5kqCOTcyWOeqguk9inM+sgZEkkFFiYFXDsgz2xN0cNAZcu2podJrnptymAPPJVGECIXgwVMuAOIqM49ikuBYo4XmP9feNd/ymChdQuJUSde6P5l+Bnyhy7WcEw49x83fW0i0yoQHwoIBdmyZyQDYeg4TzZ7+GZp/+nRB/1f1HeaE4FbfamWgjoSk7Z/p/uFYl 93ONP76X DWrtqjAfUlV0ZmRpmGQqg00wB1ivJTEVANQRHcEyaVakE0WQXlOZtT9v990jvk1ARz5SQgGUfprpdaXsPl1j3XvPnmsvvVVB40AqIVwEo1272KskMdSbBTgJVokaExtMK15lqYm4h6RYP0mFTPijr/eAyGmojmvCE/pQulpd/RF02LEdiLiRWqu1Lk7vdXkc0jOh8bUj3TuWvP0JhO6vyzXcU3g== 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 Mon, Nov 18, 2024 at 08:55:33PM +0200, Leon Romanovsky wrote: > On Mon, Nov 18, 2024 at 02:59:30PM +0000, Will Deacon wrote: > > On Sun, Nov 10, 2024 at 03:46:54PM +0200, Leon Romanovsky wrote: > > > +static void __iommu_dma_iova_unlink(struct device *dev, > > > + struct dma_iova_state *state, size_t offset, size_t size, > > > + enum dma_data_direction dir, unsigned long attrs, > > > + bool free_iova) > > > +{ > > > + struct iommu_domain *domain = iommu_get_dma_domain(dev); > > > + struct iommu_dma_cookie *cookie = domain->iova_cookie; > > > + struct iova_domain *iovad = &cookie->iovad; > > > + dma_addr_t addr = state->addr + offset; > > > + size_t iova_start_pad = iova_offset(iovad, addr); > > > + struct iommu_iotlb_gather iotlb_gather; > > > + size_t unmapped; > > > + > > > + if ((state->__size & DMA_IOVA_USE_SWIOTLB) || > > > + (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))) > > > + iommu_dma_iova_unlink_range_slow(dev, addr, size, dir, attrs); > > > + > > > + iommu_iotlb_gather_init(&iotlb_gather); > > > + iotlb_gather.queued = free_iova && READ_ONCE(cookie->fq_domain); > > > + > > > + size = iova_align(iovad, size + iova_start_pad); > > > + addr -= iova_start_pad; > > > + unmapped = iommu_unmap_fast(domain, addr, size, &iotlb_gather); > > > + WARN_ON(unmapped != size); > > > > Does the new API require that the 'size' passed to dma_iova_unlink() > > exactly match the 'size' passed to the corresponding call to > > dma_iova_link()? I ask because the IOMMU page-table code is built around > > the assumption that partial unmap() operations never occur (i.e. > > operations which could require splitting a huge mapping). We just > > removed [1] that code from the Arm IO page-table implementations, so it > > would be good to avoid adding it back for this. > > dma_iova_link/dma_iova_unlink() don't have any assumptions in addition > to already existing for dma_map_sg/dma_unmap_sg(). In reality, it means > that all calls to unlink will have same size as for link. Ok, great. Any chance you could call that out in the documentation patch, please? Will