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 EA650C369CB for ; Sat, 26 Apr 2025 22:46:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF6026B0006; Sat, 26 Apr 2025 18:46:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D7DC36B0007; Sat, 26 Apr 2025 18:46:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF7216B0008; Sat, 26 Apr 2025 18:46:34 -0400 (EDT) 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 9E6F16B0006 for ; Sat, 26 Apr 2025 18:46:34 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 272F51609C6 for ; Sat, 26 Apr 2025 22:46:35 +0000 (UTC) X-FDA: 83377680750.01.3C0211A Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf13.hostedemail.com (Postfix) with ESMTP id 8B79120004 for ; Sat, 26 Apr 2025 22:46:33 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YKGaQruU; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf13.hostedemail.com: domain of mcgrof@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=mcgrof@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745707593; a=rsa-sha256; cv=none; b=PPvnMRqPX1zh9xoN1c36DGp4y9PuSeuKmLj9rAH2ezlzJ//Ws5O2b2s6LTGrT8ynMkWyrG +6Ju/9AkGWw7dklaMGMtPJmNkkYwIf34dYgHn1+F1oXKGv+bLcc2wSmrIIyarFQTWtV8yz vzVfY2LMUPl+vU4kG8nV4BotP23Bp7c= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YKGaQruU; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf13.hostedemail.com: domain of mcgrof@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=mcgrof@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745707593; 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=9iJH05flBZYZade1Q4AdF0jFljOufYmw1jcj0Sa8j/E=; b=xu6pGM5MvtgY+CALqrZ+KRhCE2Yds8TsI7QlM1Xri1EwmIdNnAR3t2cj89IwvZhx48It3Y E2Y9FiRrXZbSdQE+pu6+a1dJcBMmvrJqPb3gRvlLSFeroaNWd7/Kl2m3SY1y/XSYUkwb9f r8jf09q9gPC5oB41JFtjE2qed2O7QHI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 879F460008; Sat, 26 Apr 2025 22:46:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69CF1C4CEE2; Sat, 26 Apr 2025 22:46:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745707592; bh=it71BWM3Pceo9WRIYilwNRCMXHq8+IvGJApDek517BE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YKGaQruU+xGKGdoV3l0Vdfka/Y45JUZ628iUFoujF9GwWY3FxppXFkzRMUG35MpSg EaiOBb12LBgx+b82Q725iKeAXZvDOQrTrYDbpjGsFJD/9JoTAfzclwS22FBORZc6ek YrQeuCfAS9736Zz+L8ezEhzujNRGjLTWdfKLTu8z+Sj/Nf/KYu+5QuqEX0RYVcxQVu iuNkpiXmoht3Sz9eAnub+4DM+HlcT4q+qLJWPn7TfVySmbrV5ShZFLhZN6chXawY7/ o0K1zUEdi2U8Gb27lMdTVWTZAdL8kVWJyUyes55gZ+Haf+mBp0qPllLRO9rYmNiAcI bgflnweJDU5Mw== Date: Sat, 26 Apr 2025 15:46:30 -0700 From: Luis Chamberlain To: Leon Romanovsky Cc: Marek Szyprowski , Jens Axboe , Christoph Hellwig , Keith Busch , Leon Romanovsky , Jake Edge , Jonathan Corbet , Jason Gunthorpe , Zhu Yanjun , Robin Murphy , Joerg Roedel , Will Deacon , Sagi Grimberg , Bjorn Helgaas , Logan Gunthorpe , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , =?iso-8859-1?B?Suly9G1l?= Glisse , 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, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, Niklas Schnelle , Chuck Lever , Matthew Wilcox , Dan Williams , Kanchan Joshi , Chaitanya Kulkarni Subject: Re: [PATCH v9 07/24] dma-mapping: Implement link/unlink ranges API Message-ID: References: <2d6ca43ef8d26177d7674b9e3bdf0fe62b55a7ed.1745394536.git.leon@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d6ca43ef8d26177d7674b9e3bdf0fe62b55a7ed.1745394536.git.leon@kernel.org> X-Rspamd-Queue-Id: 8B79120004 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: kftkuoz9ng5ap3drudy7tedn6pj5w9kz X-HE-Tag: 1745707593-267311 X-HE-Meta: U2FsdGVkX19EJFt80NoKIJ38ju96AvEOvqghJ4G6CnCwmGx5RNrkZPsQoIKdkmRoCDy1XST0g+vpARVhUVqu6lR2UDY5ZKX2frWoqJVUdzZaZKiTWMm8ivuuE/LZvk3O5hqggtXycrZIipcNfYbkmh6pWC0GPefwYNJY7+PSSRAOpK7hObEX5mBqr7Dz5K4QEgYhrLBBfIVF8hZUjlMelHS5Z8ZWu+L6yM2YOwfAo4Eh6JdbRUsoOWu90ewKo2N4yJK6ga2tcNpx36KnDN2+wgzHReHFLS+syyaJQCFtEwyfbAJGWo5oH9IKzifHQ7cd3L8eeEldrWAGkd0TgQbZigL/gTY0J3jUBe/mSafU5kZFUw3rdmyZ6h9q+BBEkqdt7nU/nqsy4PsyrgxEbAU2YYTJg2EFvzANWErh7pYwAKm+YoVBaI5F1dz2WtU7i38AA0+bQcqoAKETSgYxMJ/Kis9bg/7j6arTrlknhkcEDkpQZB7gpuFk3C2zZ3NF39TazEROIv1mCLf5WrwSgAp8IyQvkllptG8BT3WIie+9P5qKM3NLsVN6s0VH5N7bKm9QArydYQRSRODGhP/QtYmbHrQxHM3LwfU5XP2bDTissbttUclUEl1EZYHpgTcAxfNv0Tn1aGu3a8W1E3rWiXvzUJZwC7dtyBqgfDmz7E0PhQTz21MaXW/QqUds2IS1MWTquqqPgPG/L02+sduiXJBfjWe7chDxEo26uDU4SAyCfJYJDFC/fkMaDEtx2vC0RfvBkI+dEOFc8AXSXxWTRgegTOC0fxtodHSKdquKLG8puiGucKB6K/y8olUJbMvL1cfvJMz6IhstHyRUe2X1OfaXcj2bxY6Lpz1vHh6Et7Kg/CRw6eBZprc1RLfJE2Yi3Q/qEY+N57r4tSNYimG+F8F2jmaT4QUAIKO51H56mKBS0dfpbrPqZGNAB7p8ZlSsWnTgeemPsbFTZky4jWieeTC J75ppX6o /NCUvhUunTSbHfU5Nf9jZeybCgHQH7LlfjeggRX24YtiD/G3LJ6X/dLV9BGf0b7GfqUYbRIKaJ9f/l3wu4xe1fjqq62zT8cjLsk9pNE/QzgDzTHTju5XVlAoRf8yq8hXkK1vVWUY9no6+CNT4BUUI+UCSthfsWv/V8fhdWrOBNsC55E6GMGz+e2aq0HWZNhOAOTUiQ8e+/0zF/ZjWhF8aCoY/FiIeRJEfIgwt0uc4/6wXU3+ytjD394nbAcrWt8EXvyvt 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 Wed, Apr 23, 2025 at 11:12:58AM +0300, Leon Romanovsky wrote: > From: Leon Romanovsky > > Introduce new DMA APIs to perform DMA linkage of buffers > in layers higher than DMA. > > In proposed API, the callers will perform the following steps. > In map path: > if (dma_can_use_iova(...)) > dma_iova_alloc() > for (page in range) > dma_iova_link_next(...) > dma_iova_sync(...) > else > /* Fallback to legacy map pages */ > for (all pages) > dma_map_page(...) > > In unmap path: > if (dma_can_use_iova(...)) > dma_iova_destroy() > else > for (all pages) > dma_unmap_page(...) > > Reviewed-by: Christoph Hellwig > Tested-by: Jens Axboe > Signed-off-by: Leon Romanovsky > --- > drivers/iommu/dma-iommu.c | 261 ++++++++++++++++++++++++++++++++++++ > include/linux/dma-mapping.h | 32 +++++ > 2 files changed, 293 insertions(+) > > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c > index d2c298083e0a..2e014db5a244 100644 > --- a/drivers/iommu/dma-iommu.c > +++ b/drivers/iommu/dma-iommu.c > @@ -1818,6 +1818,267 @@ void dma_iova_free(struct device *dev, struct dma_iova_state *state) > } > EXPORT_SYMBOL_GPL(dma_iova_free); > > +static int __dma_iova_link(struct device *dev, dma_addr_t addr, > + phys_addr_t phys, size_t size, enum dma_data_direction dir, > + unsigned long attrs) > +{ > + bool coherent = dev_is_dma_coherent(dev); > + > + if (!coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) > + arch_sync_dma_for_device(phys, size, dir); So arch_sync_dma_for_device() is a no-op on some architectures, notably x86. So since you're doing this work and given the above pattern is common on the non iova case, we could save ourselves 2 branches checks on x86 on __dma_iova_link() and also generalize savings for the non-iova case as well. For the non-iova case we have two use cases, one with the attrs on initial mapping, and one without on subsequent sync ops. For the iova case the attr is always consistently used. So we could just have something like this: #ifdef CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE static inline void arch_sync_dma_device(struct device *dev, phys_addr_t paddr, size_t size, enum dma_data_direction dir) { if (!dev_is_dma_coherent(dev)) arch_sync_dma_for_device(paddr, size, dir); } static inline void arch_sync_dma_device_attrs(struct device *dev, phys_addr_t paddr, size_t size, enum dma_data_direction dir, unsigned long attrs) { if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) arch_sync_dma_for_device(paddr, size, dir); } #else static inline void arch_sync_dma_device(struct device *dev, phys_addr_t paddr, size_t size, enum dma_data_direction dir) { } static inline void arch_sync_dma_device_attrs(struct device *dev, phys_addr_t paddr, size_t size, enum dma_data_direction dir, unsigned long attrs) { } #endif > +/** > + * dma_iova_link - Link a range of IOVA space > + * @dev: DMA device > + * @state: IOVA state > + * @phys: physical address to link > + * @offset: offset into the IOVA state to map into > + * @size: size of the buffer > + * @dir: DMA direction > + * @attrs: attributes of mapping properties > + * > + * Link a range of IOVA space for the given IOVA state without IOTLB sync. > + * This function is used to link multiple physical addresses in contiguous > + * IOVA space without performing costly IOTLB sync. > + * > + * The caller is responsible to call to dma_iova_sync() to sync IOTLB at > + * the end of linkage. > + */ > +int dma_iova_link(struct device *dev, struct dma_iova_state *state, > + phys_addr_t phys, size_t offset, size_t size, > + enum dma_data_direction dir, unsigned long attrs) > +{ > + struct iommu_domain *domain = iommu_get_dma_domain(dev); > + struct iommu_dma_cookie *cookie = domain->iova_cookie; > + struct iova_domain *iovad = &cookie->iovad; > + size_t iova_start_pad = iova_offset(iovad, phys); > + > + if (WARN_ON_ONCE(iova_start_pad && offset > 0)) > + return -EIO; > + > + if (dev_use_swiotlb(dev, size, dir) && iova_offset(iovad, phys | size)) There is already a similar check for the non-iova case for this on iommu_dma_map_page() and a nice comment about what why this checked, this seems to be just screaming for a helper: /* * Checks if a physical buffer has unaligned boundaries with respect to * the IOMMU granule. Returns non-zero if either the start or end * address is not aligned to the granule boundary. */ static inline size_t iova_unaligned(struct iova_domain *iovad, phys_addr_t phys, size_t size) { return iova_offset(iovad, phys | size); } Other than that, looks good. Reviewed-by: Luis Chamberlain Luis