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 D1A45C47258 for ; Mon, 4 May 2020 16:44:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 95F38207DD 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" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95F38207DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1EA868E0063; Mon, 4 May 2020 12:44:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19B058E0058; Mon, 4 May 2020 12:44:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08A4B8E0063; Mon, 4 May 2020 12:44:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id E08DF8E0058 for ; Mon, 4 May 2020 12:44:03 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 99F1C824559C for ; Mon, 4 May 2020 16:44:03 +0000 (UTC) X-FDA: 76779608766.24.beam87_5d9d5c6852629 X-HE-Tag: beam87_5d9d5c6852629 X-Filterd-Recvd-Size: 5430 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 16:44:03 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id x17so21776121wrt.5 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=VxUbp8AUsHDY9YRllndKZDMW5ehgpg2US7llTQdgwG3VAe0ZkZB3GMtX4dySfPvi2w ywYOu+73VsHZRk16sspnZyfQMwl2p2CMtY695+TF681sxyclZ1IJFU3j5B/uWZ7myYE7 42YlkHYuACKS3D2mj2KtTMlJqai1xzvLfWAkiXCFKGGPr4AcH6V10jszlb8f7IkHvPSN hHkljOx/dEQ0OZ6xn0frYyPDleecNIw92oMDQ1hPlpKyPC7bc8jWOiJSVcfufg4HuCWh KuJ/4Swy+rNe36rxPpOpuAD4GG5yLMNdZg/BxiZ2Bm1GC9QZVPnIODJVYuSOMHXdMPJc nqXQ== X-Gm-Message-State: AGi0PubVUvp9jtq4hyMaWhPwAz2p3NeBkVzxMG8MAtsjH+zBu0Bdj2DK 77PzYi7Vm+lpOtg6wdj2vtDOxg== 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> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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