From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD97735AC24 for ; Sun, 31 May 2026 23:51:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780271514; cv=none; b=GoIDRM7+aR2TG+9/nfPL+QCQz8TVWFMozWgPctPKhjaiaUGVC4h1sZgvLqiHVIV3L6+hLXtBxoVhL2wUxHJcs0dZzi2hA4nZHaJCyTQMbAPTbaQR9aKGX8i6EheyR+CahXKjk1TTYXFY974oCZHFJHw8/1TFLyYDnmg5AgwWH7I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780271514; c=relaxed/simple; bh=vZPmrTp86MbPzKorp7nUexYwkpoU7a/NNFPpiXKZRk4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pt7R952tdwaO3hmyoCsnqPksEQsg2rYNgDXFI5/L7xiEW7s63Ys+Zk/XewY3DiAr5ZQDfUkUWs6n6G+C3O/K0KIejv6nhS2jxZ7hceNapYyftBNpwhfs6CraHX8gw8vVmiHix0KMw1y/3IFMLD6KJmkdKL5J0hpVY6dIYnH9Hh0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=Fnlf4ZCm; arc=none smtp.client-ip=209.85.222.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="Fnlf4ZCm" Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-915671abde5so5357785a.3 for ; Sun, 31 May 2026 16:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1780271511; x=1780876311; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=jT2+faPEqgvyyrZj7GkiI+MQEalHKPFUv4mZyF5by/U=; b=Fnlf4ZCm2UukdbJ7WNpGo0A0yW7Npk87rwKL0VGMpBGnIApxYLtL8QqqV4hNVSzyCW M9y42dI/gD2bUo+FQhbzHCpxNqHlL8fSQZI97xIpRT4/fmD1bUeAE5PGr5bA7Olw9+d7 9eStj3xrew4cMILG3e+1elSjtAN3GUDfpY/PfrEY4YcmAutANUps1iDCV6DFMpQB4RHZ 1eknFPeAr1J5ATNAAnavOjIY4QtS9KGy5lc+lxPHKEkQMNdNeo7S5A306pp99h+aOOMz FvyuG60UNBT1oMJWsvbhQeUs06Qb046zmq63p3UxexU3480Q6+Xs4/TlL1AYwv4HHALH ACsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780271511; x=1780876311; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jT2+faPEqgvyyrZj7GkiI+MQEalHKPFUv4mZyF5by/U=; b=pla6dtniSr0Z9r/retV1yvAIRXUy5N+7AldmEEoMst6R6/Xa/ZjEUX8Ho1xOmWLNtS L7phjM2fiuoKYlPdQQ5WNaYHASkhGO4QoJY/of7c2TVuAJIes74LDkUotcw7APhTD/BQ hJxQ/6dWEdM3qGLl1VyfbpJp/E/mdREqqurD7GZYLodGjrPEJaHNuSkcBS4mQ/WYaq31 v5326asrj7BKnvUIfHmqcGTjsnjQqBfB9L3QFYVTsUZ/+3zawqtCGRVuGrscm9f7T5+4 xYfFBWrsjw4YwxEsZ71V7RxacoRInjg+MKnFbWmmrtCUmZ69oKkc7su9VZfL0/1luWdQ 0iGg== X-Forwarded-Encrypted: i=1; AFNElJ9PHqNIqqWzrdVLKYsUxiC2MaHIZ42DdKabQMx1n+FVLyuXgBKBqc7aJJ2wEDzhE2JdiqXXMC4n3A82MDs=@vger.kernel.org X-Gm-Message-State: AOJu0Yytow4rywJuu5WqtQfBdMugkg9brbfWp0PX48bx/oN7XVkGujLh U3Oht5Jc3uraFhUlQLEgjAAunmSepGogYWiWy4hrGzge+XOME3vqgQcju695Y8CLREU= X-Gm-Gg: Acq92OGsBPlaPb/cK5EzcElcUpbMcNnxQ2CJ2kID+p4asikJfzbJ5Vqp/HgLWFwq8ct r5WpH8tVWAy+za8jbyJL6AXmX0TwmvIiXNyqf1QgSSYqvq7tjlpoxanrgrvjAFwQES/Vm0YLIsB 7hQ/CyJmxfVoKisE1SxdZyVWJFnxX3BXuuXiNGZEUqIC8d/ipdsXsmH9TXIQ+Sp46QOqKhDKItm aq4Cu0tI12jzTRyy1DJL4BlIBqGypntZgtGudMGqHorogdRzRLmw7MqCQZVV9YaCbeVkAxNjYl8 DlQfKUrdyerYPa74Zn0YjDuqMqR4WLktPkT1TWIoQJh3PNdw0pciuvXlc83NFoG6Mulw1GD52oh UC0np/gWD0XWmb8ycUSf4DlLPtpAdpCm6m0koeJWI0O1SgZLFcfZu+5bOmfcpfGerUkPc/IkQVz SnaTv2JLLDLNt5ZcUiaTFixy04Y7Fn3qy5gMHV449jaWDa8C1+qDntMkzk7VTn4AqEV5kG0ayto U+bixPZ9ktJgq5u X-Received: by 2002:a05:620a:439b:b0:913:7bc8:79b9 with SMTP id af79cd13be357-9153d9b617bmr1323643185a.22.1780271510817; Sun, 31 May 2026 16:51:50 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id af79cd13be357-91532473bb9sm854276585a.11.2026.05.31.16.51.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 May 2026 16:51:50 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wTpwa-00000001LoH-3dmS; Sun, 31 May 2026 20:51:48 -0300 Date: Sun, 31 May 2026 20:51:48 -0300 From: Jason Gunthorpe To: Guanghui Feng Cc: boris.brezillon@collabora.com, robh@kernel.org, steven.price@arm.com, adrian.larumbe@collabora.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, liviu.dudau@arm.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, alex@shazbot.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kevin.tian@intel.com, baolu.lu@linux.intel.com, suravee.suthikulpanit@amd.com, dwmw2@infradead.org, xlpang@linux.alibaba.com, oliver.yang@linux.alibaba.com, shiyu.zsq@linux.alibaba.com, wei.guo.simon@linux.alibaba.com Subject: Re: [PATCH 1/9] iommu: introduce iova_to_phys_length in iommu_domain_ops Message-ID: <20260531235148.GV2487554@ziepe.ca> References: <20260529115116.GR2487554@ziepe.ca> <20260531093637.3893199-1-guanghuifeng@linux.alibaba.com> <20260531093637.3893199-2-guanghuifeng@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260531093637.3893199-2-guanghuifeng@linux.alibaba.com> On Sun, May 31, 2026 at 05:36:29PM +0800, Guanghui Feng wrote: > Add iova_to_phys_length callback to struct iommu_domain_ops alongside > the existing iova_to_phys. The new callback returns both the physical > address and the PTE mapping page size in a single page table walk. > > Add iommu_iova_to_phys_length() core function that: > - Checks ops->iova_to_phys_length first (preferred path) > - Falls back to ops->iova_to_phys for unmigrated drivers > > This enables callers like VFIO to efficiently traverse IOVA space > by actual mapping granularity instead of fixed PAGE_SIZE steps. > > Signed-off-by: Guanghui Feng > Acked-by: Shiqiang Zhang > Acked-by: Simon Guo > --- > drivers/iommu/iommu.c | 34 ++++++++++++++++++++++++++++++++-- > include/linux/iommu.h | 9 +++++++++ > 2 files changed, 41 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index d1a9e713d3a0..43323229a1df 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -2545,15 +2545,45 @@ void iommu_detach_group(struct iommu_domain *domain, struct iommu_group *group) > } > EXPORT_SYMBOL_GPL(iommu_detach_group); > > -phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova) > +/** > + * iommu_iova_to_phys_length - Translate IOVA and return mapping page size > + * @domain: IOMMU domain to query > + * @iova: IO virtual address to translate > + * @mapped_length: Output parameter for the PTE page size (e.g. 4KB/2MB/1GB) > + * > + * Like iommu_iova_to_phys() but additionally returns the page size of the > + * PTE mapping at @iova through @mapped_length. > + * > + * Return: The physical address for the given IOVA, or 0 if no translation. > + */ When introducing the new function I would like to fix this 0 error as well, it should return PHYS_MAX for error > +phys_addr_t iommu_iova_to_phys_length(struct iommu_domain *domain, > + dma_addr_t iova, > + size_t *mapped_length) > { > + if (mapped_length) > + *mapped_length = 0; > + > if (domain->type == IOMMU_DOMAIN_IDENTITY) > return iova; > > if (domain->type == IOMMU_DOMAIN_BLOCKED) > return 0; Any domain that doesn't have an op should fail, blocked is one example > > - return domain->ops->iova_to_phys(domain, iova); > + if (domain->ops->iova_to_phys_length) > + return domain->ops->iova_to_phys_length(domain, iova, > + mapped_length); > + > + /* Fallback to legacy iova_to_phys without length info */ > + if (domain->ops->iova_to_phys) > + return domain->ops->iova_to_phys(domain, iova); If it falls back it should return something sensible for the length. I suggest you approach the patch plan a little differently, the first patches should implement the new function and an iommput implementation Arrange things so the normal iova_to_phys calls the new function if it is available and discards the length. Then convert callers that can take advantage of it. Have the fallback path also compute the length by iterating internally. Finally one patch per driver implementing the new op, this could even be a second series. Don't remove iova_to_phys(), it is fine for things that don't need the length. Jason