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 8C950D1358B for ; Mon, 28 Oct 2024 01:24:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 195846B008A; Sun, 27 Oct 2024 21:24:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 11EA16B008C; Sun, 27 Oct 2024 21:24:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB29A6B0092; Sun, 27 Oct 2024 21:24:22 -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 C9E746B008A for ; Sun, 27 Oct 2024 21:24:22 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1F08780660 for ; Mon, 28 Oct 2024 01:24:03 +0000 (UTC) X-FDA: 82721264430.03.8B4A021 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by imf26.hostedemail.com (Postfix) with ESMTP id 58527140003 for ; Mon, 28 Oct 2024 01:24:02 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YIURW7bc; spf=none (imf26.hostedemail.com: domain of baolu.lu@linux.intel.com has no SPF policy when checking 198.175.65.13) smtp.mailfrom=baolu.lu@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730078504; 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=Z4GVPapOiiK7dr/WrgAHl25aCxNyPqW9rPely3xvH6A=; b=17TwfmthiVQU+ihOeQuI9I1rzkGiFV+sW/CbJG9HdwN0Du3aRQXAMkXYnEZ8WMz8n84l+R flVfScUpTNSi+lwJJo002I2NTNe9VWCZhxHR6DtDEX0/PbGJF1bC0wDAYeYqo57ziWnPNz 0meEO8rZmW2k5DlaGF9xGSDmlM6i4h0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730078504; a=rsa-sha256; cv=none; b=eGyIQZWNOAJUsymPtM4LPw32J18lfdZN3Od9USs7U2y6KNcmtawbS2YnGPe0tOzORHh6L+ 6S1ZqOt9B3lM9DcVsquEgAB2ZzjNdNfvtzvNQtO0DAGXct6qH74Y3QyNjrqMXFb7R+TGsj z6vjoqxKwQToBt4sq1OBDTRfbGet++g= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YIURW7bc; spf=none (imf26.hostedemail.com: domain of baolu.lu@linux.intel.com has no SPF policy when checking 198.175.65.13) smtp.mailfrom=baolu.lu@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730078660; x=1761614660; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=bf/VeYucpNv6ZZcK2fwIQKDea5xGi/UZ5dimPkOuYKQ=; b=YIURW7bcE23xqiz8YIpgYH8bWnzyD4MyTr76iiXVCrbu5E14ZHjuG/2a oKsUjpudo1KLHbOlvC+d7txqYG0hnXhrfpHFmPlVPFp3k7z6lr8PxdHt6 iSalkx1khfPPIpwQyTfkpUrO2vnFdOWozbvL5kn/iiO+ky4wgY0AYqLt8 NC/P3OWCPl0MkTqp9rrQhPWQz+M4TbO/IUZKVlpTUazkLmLf48zqB0kRu qTFzw9JQyHiHUPdJzKOKUFEZxutmDzQVLKel1NXujepjvFUTZlHBs/Zbe cyX2o/Q8j5xpqePF0lHaN2k8OcNthLQjLnunFdehGdyQPlz6aKGyjZlub A==; X-CSE-ConnectionGUID: YL8fEIBVSu+pwjEblD3NVg== X-CSE-MsgGUID: fI8mVYfyTBa/kPiiGjqoeQ== X-IronPort-AV: E=McAfee;i="6700,10204,11222"; a="40769216" X-IronPort-AV: E=Sophos;i="6.11,199,1725346800"; d="scan'208";a="40769216" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2024 18:24:17 -0700 X-CSE-ConnectionGUID: 3XId+CpwRcup4hw+6LoFIA== X-CSE-MsgGUID: nYY7ZZ8XT8aQBqUAXsE3Xw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,238,1725346800"; d="scan'208";a="86065323" Received: from blu2-mobl.ccr.corp.intel.com (HELO [10.238.0.51]) ([10.238.0.51]) by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2024 18:24:10 -0700 Message-ID: <25c32551-32e2-4a44-b0ae-30ad08e06799@linux.intel.com> Date: Mon, 28 Oct 2024 09:24:08 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: baolu.lu@linux.intel.com, Leon Romanovsky , 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 Subject: Re: [PATCH 05/18] dma: Provide an interface to allow allocate IOVA To: Leon Romanovsky , Jens Axboe , Jason Gunthorpe , Robin Murphy , Joerg Roedel , Will Deacon , Christoph Hellwig , Sagi Grimberg References: <844f3dcf9c341b8178bfbc90909ef13d11dd2193.1730037276.git.leon@kernel.org> Content-Language: en-US From: Baolu Lu In-Reply-To: <844f3dcf9c341b8178bfbc90909ef13d11dd2193.1730037276.git.leon@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 58527140003 X-Stat-Signature: 4skh7zz7uoyeza9jr8jajihbey9hr33p X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1730078642-148173 X-HE-Meta: U2FsdGVkX19RkmVRdfuw0GB+oOIb6OUTjcuO12a+hlwPK/p7hKER1s4CM9mp9VcWM0fyj0Yte7Lv+vcH8l4pAXFS/WELc0Pr3dnu3dRFqFAtDjSAgVMqN/nqWzHPXM8ZoyPlOPHxbjxRwaINOnsek24P+IzLoiT+dXC5X4TWp/g0joHXi40p7T4dn7CCrp/2LlQO8KQziwjkE9KoMH+Z1yKQJIIDDAacSiNNwwbNc/Y4ynJeIgD65fICppuvcaJmOdjyGrCjyPhiS5qStHPjz9W2UsGb8mD/52lo3PYeX/PoigMArWGe0b//rT4jlHOZtX9E73Rrkg3aIPZ77Di802jk6ZhjDOi/w13iuZ3TqXhRGFcgfDUtPsETS7pacFiSgABkSYAEoYucLCGxkI4VB1ZqnfLPpMFqZymSBnofps4PleY36DTlB74uQZ55aK6BoyiaEyl3a7DqAn8H5OCAjrevNMfFhFTsfSiG0MmlODWc7wgU+o0GW9GBwPGR7DuG1R7SYZsU1evFZo1xyc7faNC/K+f7IeC5qB1RSkbraF/T6/enuQKXzqq1a+q35ot43uIlXVkxul1tJQ6byBoOJ+ycde1WsX2W9xJdFv505Tw/0XyLGvbKU/kX9fYlQK/V52h3vDOajjAMrEPMA0y0e26g675Mb69J8t2eQpC3SRkZCpDfn52H3bgQw+YLKj5YatK9PevPme6uRS0tXOzuNarEx4ZWYs9g1revnjlB9sjqev+ZifWl5oKJcwAoc8UcGHEmk91ksy0TAZYMWjEuzrxDZq71EBRvjbbH3csdihUu4Rlu11TjcknzcrZyj1zqw4zZxDVPiaJiQPIxrM2WO/lf7R+EQzX3kzNNYmqjyEQTo1HpsD4kGlPWF2Q0Z1gR/6bhEnwTcnI1rtG4nQZKJDtMRTeW5vk6fR6ZsiiHjgZutl3tzQsnJ6eUpAPJ6ElNSyw1CXX0z9N1Okd9Y0R AVPpy1ku 7PQJHI1x3iBWXToVj3PBhfWHxcGTMIFV4RcIsDsJXdJ+hY/nZTexYz/mz7kfi9j7PxBTFlh/CEmkSKQ9hHVNgvlbnrNjKvBUvGccfh/uQpdq8NUAj6GcdYHoCdpZJfgRf0wSbqcsx4NSoLXOeeQKiKcmjrAiSLe+XPH6DSZeylRYl3hUcgBZkQ0WAaU9G/urpUVW3groQOf5Uclo33HuFskRNFg== 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/10/27 22:21, Leon Romanovsky wrote: > From: Leon Romanovsky > > The existing .map_page() callback provides both allocating of IOVA > and linking DMA pages. That combination works great for most of the > callers who use it in control paths, but is less effective in fast > paths where there may be multiple calls to map_page(). > > These advanced callers already manage their data in some sort of > database and can perform IOVA allocation in advance, leaving range > linkage operation to be in fast path. > > Provide an interface to allocate/deallocate IOVA and next patch > link/unlink DMA ranges to that specific IOVA. > > The API is exported from dma-iommu as it is the only implementation > supported, the namespace is clearly different from iommu_* functions > which are not allowed to be used. This code layout allows us to save > function call per API call used in datapath as well as a lot of boilerplate > code. > > Signed-off-by: Leon Romanovsky > --- > drivers/iommu/dma-iommu.c | 79 +++++++++++++++++++++++++++++++++++++ > include/linux/dma-mapping.h | 15 +++++++ > 2 files changed, 94 insertions(+) > > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c > index c422e36c0d66..0644152c5aad 100644 > --- a/drivers/iommu/dma-iommu.c > +++ b/drivers/iommu/dma-iommu.c > @@ -1745,6 +1745,85 @@ size_t iommu_dma_max_mapping_size(struct device *dev) > return SIZE_MAX; > } > > +static bool iommu_dma_iova_alloc(struct device *dev, > + struct dma_iova_state *state, phys_addr_t phys, size_t size) > +{ > + 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_off = iova_offset(iovad, phys); > + dma_addr_t addr; > + > + if (WARN_ON_ONCE(!size)) > + return false; > + if (WARN_ON_ONCE(size & DMA_IOVA_USE_SWIOTLB)) > + return false; > + > + addr = iommu_dma_alloc_iova(domain, > + iova_align(iovad, size + iova_off), > + dma_get_mask(dev), dev); > + if (!addr) > + return false; > + > + state->addr = addr + iova_off; > + state->__size = size; > + return true; > +} > + > +/** > + * dma_iova_try_alloc - Try to allocate an IOVA space > + * @dev: Device to allocate the IOVA space for > + * @state: IOVA state > + * @phys: physical address I'm curious to know why a physical address is necessary for IOVA space allocation. Could you please elaborate? > + * @size: IOVA size > + * > + * Check if @dev supports the IOVA-based DMA API, and if yes allocate IOVA space > + * for the given base address and size. > + * > + * Note: @phys is only used to calculate the IOVA alignment. Callers that always > + * do PAGE_SIZE aligned transfers can safely pass 0 here. > + * > + * Returns %true if the IOVA-based DMA API can be used and IOVA space has been > + * allocated, or %false if the regular DMA API should be used. > + */ > +bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state, > + phys_addr_t phys, size_t size) > +{ > + memset(state, 0, sizeof(*state)); > + if (!use_dma_iommu(dev)) > + return false; > + if (static_branch_unlikely(&iommu_deferred_attach_enabled) && > + iommu_deferred_attach(dev, iommu_get_domain_for_dev(dev))) > + return false; > + return iommu_dma_iova_alloc(dev, state, phys, size); > +} > +EXPORT_SYMBOL_GPL(dma_iova_try_alloc); Thanks, baolu