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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 96295C3A5A9 for ; Mon, 4 May 2020 16:44:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6B2972068E for ; Mon, 4 May 2020 16:44:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="GVujRTu9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729598AbgEDQoE (ORCPT ); Mon, 4 May 2020 12:44:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729604AbgEDQoD (ORCPT ); Mon, 4 May 2020 12:44:03 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B856C061A0E for ; Mon, 4 May 2020 09:44:03 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id l18so11032885wrn.6 for ; Mon, 04 May 2020 09:44:03 -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=nKcmHJjl9tIFKl3vh2WZWbQ1a6qf0OFNOmjvKAG+T5w=; b=GVujRTu9LfTtfSzWvR/blDgA6L4wRuxbhYL/JkbyHQuSK8LBG1AbIRX7hrdeiN0O7Z 8Baza83dK07XMfbk20Q4GjHiYd4X4taXQr82nh40jV8dNTlKcvoKIZtYRHESbkJA0Mei m0JLe0wL6lKWe3B00KhI1No1bnfAYcK4FWXAj0PDFUuXEgS3N/NCSXdao12JT6mYvX7R wWA8cKGRE8zdnC3olLE8Amc6l6swWxcCLhl/UAEav9UYx2rkCZQF3jq3haIKHqp/B/Tc bv20hTPber8xWSwz5soOC6sjFXModYLMxNromwl4JxU9GswTWo613kfBFwjSkE/8acrI lxjw== 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=nKcmHJjl9tIFKl3vh2WZWbQ1a6qf0OFNOmjvKAG+T5w=; b=VQy5vXaC//m5OGZpTA1FoPZ/2NFe6AqX3vrowIrVaNfH3LTb4Tn3cVcCzLTuIuT4ms /+qRTY4H5WzogZ98+Gm8vCIhAuE6dwiDkNgv8+EyqrsNnLWUxt61y5N2fpp2+GdfzWVe eGw+K2gJuW2iRGBIvIHK+vq0x1AMKUhkVbG0ZcETJel6XuBgyxtWdK8QQH0SqE5oA2no JLk18kvTaTv0NC7INHgisXfxTiak9aGFXC5UCWBG/Rxx6Y/Vz8Y4lh8zfHGOc4K/XYrV vIzBxUQbOpmX/h/LjEI2UzTxeF7PflsPoRFbofv14i9Ncm2MbXOhchtnoR/wZ3d0kGAs gVMw== X-Gm-Message-State: AGi0PuaWcOU7M1Br22cZhnbl9mlBG367a+Me7CbJYXp9uU9FElnvwSUt MUjTR+HrcA51NR2bOu7ektGzpg== X-Google-Smtp-Source: APiQypIoWxNfvYjKhhuxv6cQDK75SO+JQ8441jozvjondQeZtyDNRGUJBpfXr2gHhMn+rcM5zZPzpw== X-Received: by 2002:a5d:4e0a:: with SMTP id p10mr12708701wrt.215.1588610642110; Mon, 04 May 2020 09:44:02 -0700 (PDT) Received: from myrica ([2001:171b:226e:c200:c43b:ef78:d083:b355]) by smtp.gmail.com with ESMTPSA id n12sm7101170wrj.95.2020.05.04.09.44.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 09:44:01 -0700 (PDT) Date: Mon, 4 May 2020 18:43:51 +0200 From: Jean-Philippe Brucker To: Jacob Pan Cc: iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, joro@8bytes.org, catalin.marinas@arm.com, will@kernel.org, robin.murphy@arm.com, kevin.tian@intel.com, baolu.lu@linux.intel.com, Jonathan.Cameron@huawei.com, christian.koenig@amd.com, felix.kuehling@amd.com, zhangfei.gao@linaro.org, jgg@ziepe.ca, xuzaibo@huawei.com, fenghua.yu@intel.com, hch@infradead.org Subject: Re: [PATCH v6 17/25] iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind() Message-ID: <20200504164351.GJ170104@myrica> References: <20200430143424.2787566-1-jean-philippe@linaro.org> <20200430143424.2787566-18-jean-philippe@linaro.org> <20200430141617.6ad4be4c@jacob-builder> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200430141617.6ad4be4c@jacob-builder> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Apr 30, 2020 at 02:16:17PM -0700, Jacob Pan wrote: > > +static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn, > > + struct mm_struct *mm, > > + unsigned long start, > > unsigned long end) +{ > > + /* TODO: invalidate ATS */ > > +} > > + > > +static void arm_smmu_mm_release(struct mmu_notifier *mn, struct > > mm_struct *mm) +{ > > + struct arm_smmu_mmu_notifier *smmu_mn = mn_to_smmu(mn); > > + struct arm_smmu_domain *smmu_domain; > > + > > + mutex_lock(&arm_smmu_sva_lock); > > + if (smmu_mn->cleared) { > > + mutex_unlock(&arm_smmu_sva_lock); > > + return; > > + } > > + > > + smmu_domain = smmu_mn->domain; > > + > > + /* > > + * DMA may still be running. Keep the cd valid but disable > > + * translation, so that new events will still result in > > stall. > > + */ > Does "disable translation" also disable translated requests? No it doesn't disable translated requests, it only prevents the SMMU from accessing the pgd. > I guess > release is called after tlb invalidate range, so assuming no more > devTLB left to generate translated request? I'm counting on the invalidate below (here a TODO, implemented in next patch) to drop all devTLB entries. After that invalidate, the device: * issues a Translation Request, returns with R=W=0 because we disabled translation (and it isn't present in the SMMU TLB). * issues a Page Request, returns with InvalidRequest because mmget_not_zero() fails. > > > + arm_smmu_write_ctx_desc(smmu_domain, mm->pasid, &invalid_cd); > > + > > + arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_mn->cd->asid); > > + /* TODO: invalidate ATS */ > > + > If mm release is called after tlb invalidate range, is it still > necessary to invalidate again? No, provided all mappings from the address space are unmapped and invalidated. I'll double check, but in my tests invalidate range didn't seem to be called for all mappings on mm exit, so I believe we do need this. Thanks, Jean