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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 7067EC43381 for ; Wed, 20 Jan 2021 13:13:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 24ADB23359 for ; Wed, 20 Jan 2021 13:13:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389204AbhATNMO (ORCPT ); Wed, 20 Jan 2021 08:12:14 -0500 Received: from foss.arm.com ([217.140.110.172]:59796 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387715AbhATMad (ORCPT ); Wed, 20 Jan 2021 07:30:33 -0500 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 B9747D6E; Wed, 20 Jan 2021 04:29:47 -0800 (PST) Received: from [10.57.39.58] (unknown [10.57.39.58]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3030F3F66E; Wed, 20 Jan 2021 04:29:46 -0800 (PST) Subject: Re: [RFC PATCH V2 2/2] iommu: add Unisoc iommu basic driver To: Chunyan Zhang Cc: DTML , Linux Kernel Mailing List , Chunyan Zhang , Sheng Xu , iommu@lists.linux-foundation.org, Rob Herring , Kevin Tang , Baolin Wang , Orson Zhai References: <20210108113851.354947-1-zhang.lyra@gmail.com> <20210108113851.354947-3-zhang.lyra@gmail.com> <47f73502-15fe-5d65-6fc9-22eb078d7797@arm.com> From: Robin Murphy Message-ID: <3a2561fc-65a6-4c68-fdb7-a5b670706f43@arm.com> Date: Wed, 20 Jan 2021 12:29:44 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-01-20 11:40, Chunyan Zhang wrote: [...] >>> + pgt_base_iova = dom->pgt_va + >>> + ((iova - mdata->iova_start) >> SPRD_IOMMU_PAGE_SHIFT); >>> + >>> + spin_lock_irqsave(&dom->pgtlock, flags); >>> + for (i = 0; i < page_num; i++) { >>> + pgt_base_iova[i] = pabase >> SPRD_IOMMU_PAGE_SHIFT; >> >> Out of curiosity, is the pagetable walker cache-coherent, or is this >> currently managing to work by pure chance and natural cache churn? > > ->iotlb_sync_map() was implemented in this driver, I guess that has > done what you say here? No, sync_map only ensures that the previous (invalid) PTE isn't held in the IOMMU's TLB. If pgt_va is a regular page allocation then you're writing the new PTE to normal kernel memory, with nothing to guarantee that write goes any further than the CPU's L1 cache. Thus either the IOMMU has capable of snooping the CPU caches in order to see the updated PTE value (rather than refetching the stale value from DRAM), or you're just incredibly lucky that by the time the IOMMU *does* go to fetch the PTE for that address, that updated cache line has already been evicted out to DRAM naturally. This is not an issue if you use the proper DMA allocator, since that will ensure you get a non-cacheable buffer if you need one. Robin.