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.8 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 01779C47256 for ; Tue, 5 May 2020 09:15:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B9BBC206B8 for ; Tue, 5 May 2020 09:15:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="QXWA/MYx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9BBC206B8 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 7422E8E00A4; Tue, 5 May 2020 05:15:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 718F28E0058; Tue, 5 May 2020 05:15:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62E0D8E00A4; Tue, 5 May 2020 05:15:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0037.hostedemail.com [216.40.44.37]) by kanga.kvack.org (Postfix) with ESMTP id 487258E0058 for ; Tue, 5 May 2020 05:15:43 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0A23D1D99E for ; Tue, 5 May 2020 09:15:43 +0000 (UTC) X-FDA: 76782107766.03.taste63_14c2f80c31d0f X-HE-Tag: taste63_14c2f80c31d0f X-Filterd-Recvd-Size: 5878 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 May 2020 09:15:42 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id h9so1852975wrt.0 for ; Tue, 05 May 2020 02:15:42 -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=sU7U3FhjLtetQ4yGftkHmkBqFM+M9ZWPk430QlcmjSw=; b=QXWA/MYxeBeYOjAoqaNN2WaAGPU0Tv3zhPwTqxa96+5wzt9CdxYYAAOCUz6pWhuzUl 933MuJKNFPVD3w9C/QvD/C0e6iA+FZPTltexAp+raUdXk9hamFndUJbWV2K4iPOJiiz7 mqMyTD/SmVD6T8yeuC7kKEIaQK7SAcsO3TOplzzSgBS/tPHNt0Is/ZMyXCEdT7r2D46z FIOLqY+T6XzzhHEgdFXwAFjHT0v74ZucOnNkxFTOaVA8+6OV7MLwC5bHsfh2sv+sT888 szyzUg2wNsB84mYvmwLGhiEl0EZfJEPVQVC4y7fppcLdtB5gerYO6mRdLiS7XmYwmwZ0 XEWA== 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=sU7U3FhjLtetQ4yGftkHmkBqFM+M9ZWPk430QlcmjSw=; b=f/bfKCPGzwAz1uTs+ISgnbAE8v7GYSO9Q+mzS5MZPn4cWXkAGt0fQY0uQLE3X2+c/7 cbQGg02QtSFIRqGlyQ8z4cnXwRwPhaB76y2P53mQ2I87lXZaGZQ+9wfarr0KpWiEi/di 0Bc1lTnpX2WIUfQ6kLwGwSCZtZ2qiom4e4vM4ZFTRWGhVU80PdkWOzI0nI26Zq+ergls d2mMGH+adKdo01nKjIHetDG6g/3oDojk0GPX9U0MKVmmz5oM+JWWMZwS2c/lHzAX3sLm CnZNP5U5iOexzzrfwVGe+SNUCoSdkjIVgFdwwzgwZbjYGDzfKEy9/MWMV+vCuIrShl2w d3ew== X-Gm-Message-State: AGi0PuZY33veBM7yqiDKLp9LD+uXjPRw96Hg9K2Em1fUGYAC7XOIimbk 281pp5HxBxD6uei7JvRbAevK4w== X-Google-Smtp-Source: APiQypLUdwS9EMNq1wqY/xPjJM+u52dIVylq937W1BwIZPG2UftDefGXQhpqhk5pltip4j2URFGphQ== X-Received: by 2002:a5d:4652:: with SMTP id j18mr2063792wrs.19.1588670141301; Tue, 05 May 2020 02:15:41 -0700 (PDT) Received: from myrica ([2001:171b:226e:c200:c43b:ef78:d083:b355]) by smtp.gmail.com with ESMTPSA id c190sm2856893wme.4.2020.05.05.02.15.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2020 02:15:40 -0700 (PDT) Date: Tue, 5 May 2020 11:15:31 +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: <20200505091531.GA203922@myrica> References: <20200430143424.2787566-1-jean-philippe@linaro.org> <20200430143424.2787566-18-jean-philippe@linaro.org> <20200430141617.6ad4be4c@jacob-builder> <20200504164351.GJ170104@myrica> <20200504134723.54e2ebcd@jacob-builder> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200504134723.54e2ebcd@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 Mon, May 04, 2020 at 01:47:23PM -0700, Jacob Pan wrote: > > > > + 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. > > > I think it is safe to invalidate again. There was a concern that mm > release may delete IOMMU driver from the notification list and miss tlb > invalidate range. I had a hard time to confirm that with ftrace while > killing a process, many lost events. > If it helps, I have a test that generates small DMA transactions on a SMMU model. This is the trace for a job on a 8kB mmap'd buffer: smmu_bind_alloc: dev=0000:00:03.0 pasid=1 dev_fault: IOMMU:0000:00:03.0 type=2 reason=0 addr=0x0000ffff860e6000 pasid=1 group=74 flags=3 prot=2 dev_page_response: IOMMU:0000:00:03.0 code=0 pasid=1 group=74 dev_fault: IOMMU:0000:00:03.0 type=2 reason=0 addr=0x0000ffff860e7000 pasid=1 group=143 flags=3 prot=2 dev_page_response: IOMMU:0000:00:03.0 code=0 pasid=1 group=143 smmu_mm_invalidate: pasid=1 start=0xffff860e6000 end=0xffff860e8000 smmu_mm_invalidate: pasid=1 start=0xffff860e6000 end=0xffff860e8000 smmu_mm_invalidate: pasid=1 start=0xffff860e8000 end=0xffff860ea000 smmu_mm_invalidate: pasid=1 start=0xffff860e8000 end=0xffff860ea000 smmu_unbind_free: dev=0000:00:03.0 pasid=1 And this is the same job, but the process immediately kills itself after launching it. smmu_bind_alloc: dev=0000:00:03.0 pasid=1 dev_fault: IOMMU:0000:00:03.0 type=2 reason=0 addr=0x0000ffffb9d15000 pasid=1 group=259 flags=3 prot=2 smmu_mm_release: pasid=1 dev_page_response: IOMMU:0000:00:03.0 code=0 pasid=1 group=259 dev_fault: IOMMU:0000:00:03.0 type=2 reason=0 addr=0x0000ffffb9d15000 pasid=1 group=383 flags=3 prot=2 dev_page_response: IOMMU:0000:00:03.0 code=1 pasid=1 group=383 smmu_unbind_free: dev=0000:00:03.0 pasid=1 We don't get any invalidate_range notification in this case. Thanks, Jean