Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5792582ybp; Tue, 15 Oct 2019 05:14:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqx02LY0yubUe38ZCsHjPRk+AIlVxUcHu+WiwQ7+I9Ek8D6qOYp6hOC0rn6sSwiqVkebrHiJ X-Received: by 2002:a17:906:1b0c:: with SMTP id o12mr13720024ejg.312.1571141664484; Tue, 15 Oct 2019 05:14:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571141664; cv=none; d=google.com; s=arc-20160816; b=sbEXkv9Z1RCDkMj5i2SZMDZJRW4fNtPDjKtCbNiy95w1Ar1YBf1HrTqdsv/ZQvcdMN Qfxzxoc16iyCRRFiscPAumeAJ5RoK5/oZ8SWhNrgPwPDuzNNfkBszFEN9AvkxTSKkM1J KWr6mtZ57ofrf1h8Ne0BjtY5eUDZ1I0+znbJKkM3j8myu+lGUVYiVJsEFXYyRmM4Pskg BZNkAjpnl8FdhHlaeF18UTqiWiY4tLklEHop8g6WHpejeTOxTA8L8ksaPe/SeNExMTN+ w0o/LkO2tnrrttN5AbJZRpxpZfP0OKOx9YMOkRJBwZEZXf3oIEbTOdD9/iJKPXp2GVYI HFKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=5vB8+KewMOSM0UOhypwHpOqYUeMdNHtsiQ3a3TzSAXs=; b=Udb9sZQDQL2IfhIlUIwYtVPIXU0Onkaxdx/XpCIxYLCPaYJeyST00lls+XR9lhkrVV zIfNlyZhkgJ9p0TaKtc9qCGmbIaLarym8/8zMcYER3FYsPFmLjSFoDbfEu7seiZT+aCE IJqja7/z8KWp2J/jF2X+KYCu3xjmwVv/tW8ZA+l/Mgc+ESjr+IvY0vaQZXy2U78Z1h4u l+KojPB7++EWd6rgpDfXP2BhNxzsQUvG5JOhFtbrHdDFPLAk+gTEze9M0pvpAsxPyTxg jw40gAuzLleMbuvm+332UetvZTYfrhtQkT6Twquvr/jDnVNYC0SI+0CVKJfvt4vI2m2k wxsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h17si14644462edb.89.2019.10.15.05.14.00; Tue, 15 Oct 2019 05:14:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728910AbfJOLik (ORCPT + 99 others); Tue, 15 Oct 2019 07:38:40 -0400 Received: from foss.arm.com ([217.140.110.172]:36630 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726927AbfJOLij (ORCPT ); Tue, 15 Oct 2019 07:38:39 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 28B18337; Tue, 15 Oct 2019 04:38:39 -0700 (PDT) Received: from [10.1.197.57] (e110467-lin.cambridge.arm.com [10.1.197.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F0F553F68E; Tue, 15 Oct 2019 04:38:36 -0700 (PDT) Subject: Re: [PATCH v3 3/7] iommu/mediatek: Use gather to achieve the tlb range flush To: Yong Wu Cc: Matthias Brugger , Joerg Roedel , Will Deacon , Evan Green , Tomasz Figa , linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, youlin.pei@mediatek.com, Nicolas Boichat , anan.sun@mediatek.com, cui.zhang@mediatek.com, chao.hao@mediatek.com, edison.hsieh@mediatek.com References: <1571035101-4213-1-git-send-email-yong.wu@mediatek.com> <1571035101-4213-4-git-send-email-yong.wu@mediatek.com> <1571117166.19130.83.camel@mhfsdcap03> From: Robin Murphy Message-ID: <5d03ebcb-0cd1-a9ad-0f4e-c219e351396c@arm.com> Date: Tue, 15 Oct 2019 12:38:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1571117166.19130.83.camel@mhfsdcap03> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/10/2019 06:26, Yong Wu wrote: > On Mon, 2019-10-14 at 15:21 +0100, Robin Murphy wrote: >> On 14/10/2019 07:38, Yong Wu wrote: >>> Use the iommu_gather mechanism to achieve the tlb range flush. >>> Gather the iova range in the "tlb_add_page", then flush the merged iova >>> range in iotlb_sync. >>> >>> Note: If iotlb_sync comes from iommu_iotlb_gather_add_page, we have to >>> avoid retry the lock since the spinlock have already been acquired. >> >> I think this could probably be even simpler - once the actual >> register-poking is all confined to mtk_iommu_tlb_sync(), you should be >> able get rid of the per-domain locking in map/unmap and just have a >> single per-IOMMU lock to serialise syncs. The io-pgtable code itself >> hasn't needed external locking for a while now. > > This is more simpler! Thanks very much. I will try this. > > The only concern is there is no lock in the iova_to_phys then, maybe use > the new lock instead. iova_to_phys isn't issuing any syncs, so you don't need any locking there - if anyone calls that in a way which races against the given address being unmapped and remapped they can't expect a meaningful result anyway. Robin. >>> Suggested-by: Tomasz Figa >>> Signed-off-by: Yong Wu >>> --- >>> 1) This is the special case backtrace: >>> >>> mtk_iommu_iotlb_sync+0x50/0xa0 >>> mtk_iommu_tlb_flush_page_nosync+0x5c/0xd0 >>> __arm_v7s_unmap+0x174/0x598 >>> arm_v7s_unmap+0x30/0x48 >>> mtk_iommu_unmap+0x50/0x78 >>> __iommu_unmap+0xa4/0xf8 >>> >>> 2) The checking "if (gather->start == ULONG_MAX) return;" also is >>> necessary. It will happened when unmap only go to _flush_walk, then >>> enter this tlb_sync. >>> --- >>> drivers/iommu/mtk_iommu.c | 29 +++++++++++++++++++++++++---- >>> drivers/iommu/mtk_iommu.h | 1 + >>> 2 files changed, 26 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c >>> index 5f594d6..8712afc 100644 >>> --- a/drivers/iommu/mtk_iommu.c >>> +++ b/drivers/iommu/mtk_iommu.c >>> @@ -234,7 +234,12 @@ static void mtk_iommu_tlb_flush_page_nosync(struct iommu_iotlb_gather *gather, >>> unsigned long iova, size_t granule, >>> void *cookie) >>> { >>> - mtk_iommu_tlb_add_flush_nosync(iova, granule, granule, true, cookie); >>> + struct mtk_iommu_data *data = cookie; >>> + struct iommu_domain *domain = &data->m4u_dom->domain; >>> + >>> + data->is_in_tlb_gather_add_page = true; >>> + iommu_iotlb_gather_add_page(domain, gather, iova, granule); >>> + data->is_in_tlb_gather_add_page = false; >>> } >>> >>> static const struct iommu_flush_ops mtk_iommu_flush_ops = { >>> @@ -453,12 +458,28 @@ static void mtk_iommu_flush_iotlb_all(struct iommu_domain *domain) >>> static void mtk_iommu_iotlb_sync(struct iommu_domain *domain, >>> struct iommu_iotlb_gather *gather) >>> { >>> + struct mtk_iommu_data *data = mtk_iommu_get_m4u_data(); >>> struct mtk_iommu_domain *dom = to_mtk_domain(domain); >>> + bool is_in_gather = data->is_in_tlb_gather_add_page; >>> + size_t length = gather->end - gather->start; >>> unsigned long flags; >>> >>> - spin_lock_irqsave(&dom->pgtlock, flags); >>> - mtk_iommu_tlb_sync(mtk_iommu_get_m4u_data()); >>> - spin_unlock_irqrestore(&dom->pgtlock, flags); >>> + if (gather->start == ULONG_MAX) >>> + return; >>> + >>> + /* >>> + * Avoid acquire the lock when it's in gather_add_page since the lock >>> + * has already been held. >>> + */ >>> + if (!is_in_gather) >>> + spin_lock_irqsave(&dom->pgtlock, flags); >>> + >>> + mtk_iommu_tlb_add_flush_nosync(gather->start, length, gather->pgsize, >>> + false, data); >>> + mtk_iommu_tlb_sync(data); >>> + >>> + if (!is_in_gather) >>> + spin_unlock_irqrestore(&dom->pgtlock, flags); >>> } >>> >>> static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain, >>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h >>> index fc0f16e..d29af1d 100644 >>> --- a/drivers/iommu/mtk_iommu.h >>> +++ b/drivers/iommu/mtk_iommu.h >>> @@ -58,6 +58,7 @@ struct mtk_iommu_data { >>> struct iommu_group *m4u_group; >>> bool enable_4GB; >>> bool tlb_flush_active; >>> + bool is_in_tlb_gather_add_page; >>> >>> struct iommu_device iommu; >>> const struct mtk_iommu_plat_data *plat_data; >>> > >