Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S973442AbdDXQUl (ORCPT ); Mon, 24 Apr 2017 12:20:41 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33182 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S973360AbdDXQUe (ORCPT ); Mon, 24 Apr 2017 12:20:34 -0400 MIME-Version: 1.0 In-Reply-To: <20170424160030.GQ12323@arm.com> References: <1492430246-17267-1-git-send-email-sunil.kovvuri@gmail.com> <20170424144429.GI12323@arm.com> <20170424160030.GQ12323@arm.com> From: Sunil Kovvuri Date: Mon, 24 Apr 2017 21:50:32 +0530 Message-ID: Subject: Re: [PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed To: Will Deacon Cc: iommu@lists.linux-foundation.org, LAKML , LKML , robert.richter@cavium.com, Sunil Goutham Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3204 Lines: 78 On Mon, Apr 24, 2017 at 9:30 PM, Will Deacon wrote: > On Mon, Apr 24, 2017 at 09:23:16PM +0530, Sunil Kovvuri wrote: >> On Mon, Apr 24, 2017 at 8:14 PM, Will Deacon wrote: >> > On Mon, Apr 17, 2017 at 05:27:26PM +0530, sunil.kovvuri@gmail.com wrote: >> >> From: Sunil Goutham >> >> >> >> For software initiated address translation, when domain type is >> >> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior >> >> i.e return the same IOVA as translated address. >> >> >> >> This patch is an extension to Will Deacon's patchset >> >> "Implement SMMU passthrough using the default domain". >> > >> > Are you actually seeing an issue here? If so, why isn't SMMUv3 affected too? >> Yes and SMMUv3 should also be effected but as of now I don't see any use case. >> If needed, i can re-submit the patch with changes in SMMUv3 as well. > > Yes, please. > >> >> Signed-off-by: Sunil Goutham >> >> --- >> >> drivers/iommu/arm-smmu.c | 3 +++ >> >> 1 file changed, 3 insertions(+) >> >> >> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >> >> index 41afb07..2f4a130 100644 >> >> --- a/drivers/iommu/arm-smmu.c >> >> +++ b/drivers/iommu/arm-smmu.c >> >> @@ -1405,6 +1405,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain, >> >> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >> >> struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops; >> >> >> >> + if (domain->type == IOMMU_DOMAIN_IDENTITY) >> >> + return iova; >> >> + >> >> if (!ops) >> >> return 0; >> > >> > I'd have thought ops would be NULL, since arm_smmu_init_domain_context >> > doesn't allocate them for an identity domain. >> Yes ops is set to NULL. > > Argh, sorry, I completely overlooked that we return 0 in that case, rather > than the iova. > >> > I don't understand this patch. Please can you explain the problem more >> > clearly? >> AFAIK for any driver outside IOMMU there is only one way to identify >> if device is attached to >> IOMMU or not and that is by checking iommu_domain. And I don't think >> it would be appropriate >> for the driver to check domain->type before calling 'iommu_iova_to_phys()' API. >> >> The difference between IOMMU disabled and IOMMU being in passthrough >> mode is that, in the >> later case device is still attached to default domain but in former's >> case it's NULL. So there is no >> way to differentiate for the external driver whether IOMMU is in >> passthrough mode or DMA mode. >> >> And since ops is NULL in passthrough mode, 'iommu_iova_to_phys()' will >> return zero. >> >> Use case for your reference >> https://lkml.org/lkml/2017/3/7/299 >> This driver is for a NIC interface on platform which supports SMMUv2. > > Blimey, that driver is horrible, but I take your point on the API. Please > repost, fixing SMMUv3 at the same time. Sure, will re-submit the patch with SMMUv3 changes. On a separate note, if you have time, I would definitely like to know your feedback and what's horrible in that driver, probably in a different email to keep that out of scope of this patch. Thanks, Sunil.