From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (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 6F74C3803D8 for ; Mon, 1 Jun 2026 13:43:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780321406; cv=none; b=MM/nJnX3cvrFbq1laHh0C9YTZ+povPwG+KSMEr5X/6bU23LwCiD9CJFFln/EDEmTIkyzs/XyznZxur9THCl3OrfUfTXAymIVAiAv6QrMX70nGGnIPs1Mnecw32fkhWEDt23Qd9j2JDfJrCmNxATv2erQG//U6AhkTUd422eGkW4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780321406; c=relaxed/simple; bh=6MVl9gF6JoewXnXcEZQ4a8O7c6chwzYhLEtrcH4ruBk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TWbk6mukG+nlX94iiAv/aUGhfcqt5HxdXBnrLzRIkM+OkvyD1/oqFdwzh5ARqFpGoZ2d24eLWKXdSHNbJ6Pe5pPHZKC7DZER0NkL/g4Q5hRHMBb7kpogAU5MukG/PwIncmDNjqGrrEfQgpFgom77aqcpfRR2tNRR/fRBSjpZbZs= 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=R95N/46G; arc=none smtp.client-ip=209.85.219.46 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="R95N/46G" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-8ce9df31840so11369176d6.1 for ; Mon, 01 Jun 2026 06:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1780321404; x=1780926204; 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=UW5JYVSwrnBAFt5psB8n67PnIhkPqJ98B0eIWZFk1Os=; b=R95N/46Gokjw7bTbFd+PO3hc2CcDxa5E0d+/PfVzT6iL+FHDxyWVcxvv8E6dTsHgvi 7XNWJTNAH6CBt8KposFqR6yh4qgZjZYsLv7t5sQUaT/YJ20TNmU9wjdLRz94xAx2JfdA p5YWq8iSe4V8KXM0cMrflrrNZ69dIVl008/mSXja/fgBvppflFXMJV3qcfWx+OrF7srC 9M7u0JRCir5yweshjcivl9jPFl6fjrW7F/wGjOjYnc9wwQ+M/kEN3erEqGsUspRbDfhU bCZFkqcs0p4RiqyBIMztATCnGuYAw3KJaRefKbyHGq+Bn4SoQpY5Tb0IVrLKdsr398aY wgJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780321404; x=1780926204; 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=UW5JYVSwrnBAFt5psB8n67PnIhkPqJ98B0eIWZFk1Os=; b=cju2WSjQwdaXIKSJG/LoPkN5UAe1KY4L2h/x+l1BDaExiY10vb70f4u51A88q2/J/5 W7G13JYYSGciMQhuM2AtidssW7Cle65dqFdbf8h/yENURWHSrSm8/I2DEKYK/tjqffxM F53BjkjeFNNjEXNQICGzo542hIqjmKoVyuDyS8poLAIEgw5emN/JMA6MtFJZtOLaMa1T 73JOaBtAa0rsqT2wIDOQJ4gZanIbpwOMfJ1yCml3JqM5RAogd17GLvRCYC7nRIddr+Ks /svoXjkohIOoQensmt+CYFn9YdY1f7s5Pbou/yKly55LgW3jJWQBAHfPFBNzQNQ1vdBW +iOA== X-Forwarded-Encrypted: i=1; AFNElJ+nCUagrEdFAk0ttz4Hmk1V8MskSATdNXeEzywvH+sDwbeG9kWXmRyYB+GMOUJ+tQz5YzeYFA54bCidcG4=@vger.kernel.org X-Gm-Message-State: AOJu0Yy80MO+uD9jcNKLMh8txJBVV2NDfNgW+ccX5tzTh+hg2iobywN4 yazcoVWw9KbQzBuDOWJNiu1kuZs5IgWZVFGYEQiFpP4DKobtwnWgr+gDlrgsfzydyBM= X-Gm-Gg: Acq92OGQdq1KkrzdDLNwD/zR6/P9trZ+8tnMJlELq5+bARyoBumdS830xDTQgcCzElD TAkXhdkHXoCtf0YXMrJytPF9340BR1bRgnRmXfzs+K2dACZr5qaVWVw1T7wXBxSWkzqshwnnQyt jYDsm9n+0I6R4eja2uipdcHtd3B1X9JJN/IZnpj1uGKrEHVufb4KAOUyya68+Ed6N8g+wZ5ZjQV 1KJI2FEFxCgoKMTIAqaLBZemIN+oGQFZgeZUgVSd2kUaQUnob/h9+GiPGHcE+0D0MUiwE3kx2oH OswhixEJpnUPAAdHZEwprXBv/b8QCfkkBnLhYA1+GM3hlnDLdAJofKQj8c+hApfA6jse8FSanRT REin4GI8BSAunE9yI8lRLbJk0yCcbRtO638cohdQjDnmxTf1zBiSZu+8XjczlzoffpHllZnZhh2 Qp8QulZT51Osu0Cv00hPnJY6oM1TaB0onF790rxmCl3UI19bIeFXjC0VH34RcCqEwEpr42O0vJV h50bOp9cl29ot4nupO5YayIDvI= X-Received: by 2002:a05:6214:2e41:b0:8cb:fd76:e904 with SMTP id 6a1803df08f44-8ccefd62159mr193200966d6.17.1780321404292; Mon, 01 Jun 2026 06:43:24 -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 6a1803df08f44-8ccea042373sm94107096d6.9.2026.06.01.06.43.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2026 06:43:23 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wU2vK-00000001iEk-2KA6; Mon, 01 Jun 2026 10:43:22 -0300 Date: Mon, 1 Jun 2026 10:43:22 -0300 From: Jason Gunthorpe To: "guanghuifeng@linux.alibaba.com" 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, alikernel-developer Subject: Re: [PATCH 1/9] iommu: introduce iova_to_phys_length in iommu_domain_ops Message-ID: <20260601134322.GY2487554@ziepe.ca> References: <20260529115116.GR2487554@ziepe.ca> <20260531093637.3893199-1-guanghuifeng@linux.alibaba.com> <20260531093637.3893199-2-guanghuifeng@linux.alibaba.com> <20260531235148.GV2487554@ziepe.ca> 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: On Mon, Jun 01, 2026 at 04:41:48PM +0800, guanghuifeng@linux.alibaba.com wrote: > > > +/** > > > + * 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 > > Implementations such as arm_smmu_iova_to_phys/DOMAIN_NS(iova_to_phys) > all use a return value of 0 as an invalid state, so 0 is used as the > representation of an invalid state to maintain compatibility. I know, but this bad choice has already caused bugs so if we are changing everything I would prefer we fix it. > > > +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 > > In accordance with the implementation of iommu_iova_to_phys, it returns a > phy value of 0 in invalid states. Detect the invalid states by looking at ops not domain->type > > 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. > > Does this mean retaining the iommu_iova_to_phys implementation but > implementing it through domain->ops->iova_to_phys_length (mapped_length is > NULL)? Yes Jason