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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93681C433E0 for ; Thu, 9 Jul 2020 19:43:56 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 51314206DF for ; Thu, 9 Jul 2020 19:43:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wBaVfBia"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="FoBl5rfN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 51314206DF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wHzyy/1q61GuGNpD1bAZUl2eee3zLebhkDjcZU9Tga0=; b=wBaVfBiapQ8RisKHWa/Msg7i5 473aRbzKbkJYZ6OB8wj6rf+0AxxZ7ULJqcTElw7KXVadZny2szDkC2YPJTvPMN4xiFaQpGeQz1wRx 9Td2WjxBRLKIMPTZO1sAoFFsQmUezEaV4Bv/prIi04/FEddYZUS3NdKMTQiwnEL1+8XF6CmzJYB2d 5VxcHGNsu6ZBIuLOV1gqz+ZzhZUg46/s8hiKoewf0qF6/L7YCGQY2McKQZ+F+NZ/Rd61nBiigDNKx BpVpqMY6fTRPzGaThC3WvLLijIh92KpMQqzzxG5E4OgYMmmsYjUv7yLm2Do9C1VUwuwCGmicMR9Aa dnjH9onnQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtcRF-0000cQ-IW; Thu, 09 Jul 2020 19:42:33 +0000 Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtcRC-0000bt-CH for linux-arm-kernel@lists.infradead.org; Thu, 09 Jul 2020 19:42:31 +0000 Received: by mail-pl1-x642.google.com with SMTP id w17so1230601ply.11 for ; Thu, 09 Jul 2020 12:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RioqnPMkVqNkvL0qwtl83DPVR6qY0R22jJG9ZzsK4ps=; b=FoBl5rfNFNF7RvfrMZsfGQpRYnl5VL/d9OqDtLbMx7J82YIVogRqiyjg6viQRbY+2J sTW1A3ir/PtIWNZEM6ULSEO2nNc+yv0S1qyqib1pleNf+mjT5TvR0yZiIUyEcaH0FIcA ioe3ofKBxKlluH6T9my5/Q+TQeGAuzy/JsjtAUjoILV2h+JvxOmISR8UiatNtpihyrEx Y0li6/XqOccp0iEXvWrUkYdnMeokyZYkWJBDqFmSLdNTXJSeHuDXw+WJl4ZBfzWZb45Z BuIIzcn2cSkFtDqq75Cq5AcJzfZq7uM2JUab2iXercNaTm48unxLZIEoKOzu0kc4hztU Tq4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RioqnPMkVqNkvL0qwtl83DPVR6qY0R22jJG9ZzsK4ps=; b=FQr7AIsvqNFttjaoqNOshlyquArdt2zKoxdOgk0kV9jKymx43xnVOdGgQtrjzD74+R qSjW7zGPbmLth9o14n0/oS1aaDLwhCwAsFBo57PPkx+4UKyR/WG3zyzkC25Yc4YCSd2c ydQhkvi1t763bDOGQctH+dcdPGwD/3vkWSwGDp5K/2wGw332hJ/FiIC23bZizhXJ8ZJa H6JWz34sESYiPBWacMdQNstA7IASStceuQ8jws9urh8xO1vdn5g/L67UGnfNO8meBswJ xdM8lNylykpqVStdmu5JGFJxpZSjV8QRJeBmvWjOqSCQ3Z96a8wWcfl4zqYQbER7MdV6 f6DQ== X-Gm-Message-State: AOAM530qRRJ+f9lRykopzM4q1oJ0TMUeyPjgQgBkIpZgOqw31y42Oz1i diIIFrcY/QNwqKo+9q3fqJUcVw== X-Google-Smtp-Source: ABdhPJyve4niYHT9cwXeej5Gpn/TePKakafs8sB2QJi42hBXqcwUfp/cv0b8La4DdeVsv0QPYrPoZw== X-Received: by 2002:a17:90a:f014:: with SMTP id bt20mr1758584pjb.135.1594323748072; Thu, 09 Jul 2020 12:42:28 -0700 (PDT) Received: from builder.lan (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id m16sm3870910pfd.101.2020.07.09.12.42.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2020 12:42:27 -0700 (PDT) Date: Thu, 9 Jul 2020 12:40:12 -0700 From: Bjorn Andersson To: Rob Clark Subject: Re: [PATCH 2/5] iommu/arm-smmu: Emulate bypass by using context banks Message-ID: <20200709194012.GX388985@builder.lan> References: <20200709050145.3520931-1-bjorn.andersson@linaro.org> <20200709050145.3520931-3-bjorn.andersson@linaro.org> <20200709164833.GR11847@yoga> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200709_154230_798102_71829DFD X-CRM114-Status: GOOD ( 39.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jonathan Marek , Will Deacon , Joerg Roedel , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Thierry Reding , linux-arm-msm , Robin Murphy , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Laurentiu Tudor Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu 09 Jul 11:55 PDT 2020, Rob Clark wrote: > On Thu, Jul 9, 2020 at 9:56 AM Rob Clark wrote: > > > > On Thu, Jul 9, 2020 at 9:48 AM Bjorn Andersson > > wrote: > > > > > > On Thu 09 Jul 09:17 PDT 2020, Rob Clark wrote: > > > > > > > On Wed, Jul 8, 2020 at 10:01 PM Bjorn Andersson > > > > wrote: > > > [..] > > > > > @@ -678,7 +680,11 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain, > > > > > if (smmu_domain->smmu) > > > > > goto out_unlock; > > > > > > > > > > - if (domain->type == IOMMU_DOMAIN_IDENTITY) { > > > > > + /* > > > > > + * Nothing to do for IDENTITY domains,unless disabled context banks are > > > > > + * used to emulate bypass mappings on Qualcomm platforms. > > > > > + */ > > > > > + if (domain->type == IOMMU_DOMAIN_IDENTITY && !smmu->qcom_bypass_quirk) { > > > > > > > > maybe I'm overlooking something, but I think this would put us back to > > > > allocating pgtables (and making iommu->map/unmap() no longer no-ops), > > > > which I don't think we want > > > > > > > > > > You're right, we are allocating page tables for these contexts and > > > map/unmap would modify the page tables. But afaict traversal is never > > > performed, given that the banks are never enabled. > > > > > > But as drivers probe properly, or the direct mapped drivers sets up > > > their iommu domains explicitly with translation this would not be used. > > > > > > So afaict we're just wasting some memory - for the gain of not > > > overcomplicating this function. > > > > the problem is that it makes dma_map/unmap less of a no-op than it > > should be (for the case where the driver is explicitly managing it's > > own domain).. I was hoping to get rid of the hacks to use dma_sync go > > back to dma_map/unmap for cache cleaning > > That said, it seems to cause less explosions than before.. either that > or I'm not trying hard enough. Still, I think it would probably > result in unnecessary tlb inv's. > > Previously, *somehow* we seemed to end up with dma_map/unmap trying to > modify the domain that we had attached. > I might need some help to really understand the plumbing here, but this is what I read from the code and can see in my debugging... The display device will upon creation be allocated a default_domain, of type IOMMU_DOMAIN_IDENTITY - per the qcom-impl. Then you then allocate a new iommu domain on the platform bus in the display driver and attach this to the device. This will result in the group's domain being of type IOMMU_DOMAIN_UNMANAGED. But when you then invoke dma_map_single() on the display device, the map operation will acquire the iommu_group's default_domain (not domain) and as such attempt to map stuff on the IDENTITY domain. __iommu_map() will however reject this, given that the type does not have __IOMMU_DOMAIN_PAGING set. Afaict, this would happen regardless of this patch actually setting up a page table for the default_domain or not. So, afaict, you can't use dma_map_single()/dma_unmap() to operate your page table on a lately attached iommu domain. This would also imply that the display device consumes two context banks, which worries me more than the waste of page tables etc. Regards, Bjorn > BR, > -R > > > BR, > > -R > > > > > > > > > > Regards, > > > Bjorn > > > > > > > BR, > > > > -R > > > > > > > > > smmu_domain->stage = ARM_SMMU_DOMAIN_BYPASS; > > > > > smmu_domain->smmu = smmu; > > > > > goto out_unlock; > > > > > @@ -826,6 +832,10 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain, > > > > > domain->geometry.aperture_end = (1UL << ias) - 1; > > > > > domain->geometry.force_aperture = true; > > > > > > > > > > + /* Enable translation for non-identity context banks */ > > > > > + if (domain->type != IOMMU_DOMAIN_IDENTITY) > > > > > + cfg->m = true; > > > > > + > > > > > /* Initialise the context bank with our page table cfg */ > > > > > arm_smmu_init_context_bank(smmu_domain, &pgtbl_cfg); > > > > > arm_smmu_write_context_bank(smmu, cfg->cbndx); > > > > > diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h > > > > > index d172c024be61..a71d193073e4 100644 > > > > > --- a/drivers/iommu/arm-smmu.h > > > > > +++ b/drivers/iommu/arm-smmu.h > > > > > @@ -305,6 +305,8 @@ struct arm_smmu_device { > > > > > > > > > > /* IOMMU core code handle */ > > > > > struct iommu_device iommu; > > > > > + > > > > > + bool qcom_bypass_quirk; > > > > > }; > > > > > > > > > > enum arm_smmu_context_fmt { > > > > > @@ -323,6 +325,7 @@ struct arm_smmu_cfg { > > > > > }; > > > > > enum arm_smmu_cbar_type cbar; > > > > > enum arm_smmu_context_fmt fmt; > > > > > + bool m; > > > > > }; > > > > > #define ARM_SMMU_INVALID_IRPTNDX 0xff > > > > > > > > > > -- > > > > > 2.26.2 > > > > > > > > > > _______________________________________________ > > > > > iommu mailing list > > > > > iommu@lists.linux-foundation.org > > > > > https://lists.linuxfoundation.org/mailman/listinfo/iommu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel