Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp255261pxb; Tue, 12 Apr 2022 23:30:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyS8th3pagKaSUz+tGUs7C4wGzahzwhDXgDtaSq9du7YBE0V9NX9S4ccubGr5c8sZWlbBQn X-Received: by 2002:a17:902:c405:b0:158:63be:1776 with SMTP id k5-20020a170902c40500b0015863be1776mr13660236plk.107.1649831405743; Tue, 12 Apr 2022 23:30:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649831405; cv=none; d=google.com; s=arc-20160816; b=HzvBE7WjxckLcWFnrRTPGoee5Wm43tlhf89dxqQHl+nxvkJUbAvwsOK+gy7Rm8SHkK 2FyGtLy3/c1Pw19b5rRLmwH4uoNMkFgaHljf7JXM5KpxeCDMqricwZVf7tjHnbbCM0nN Dysfmzp5Gwqy9wky/6un6GALt9OFBTIAI8wT7LGfTHt++QQ7KvvQmKG/O5FKioyltKRV KZSMO0Vsa/QIQcQJhSUIqIcGK1D31W/LaOv7eI1e46xKq+ld4zN2a7jIYLRVTcNyyW14 v1O0+p8+iwAJGVsISnrhNtdI6ZWNHikYigTds+BkIcY5lZ+siOWmw2oWoEHuqw6e0Oif 0nTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=GwRjRFjhHdp3rmcuJf5D6ux2HrA19m8pAxb06b/ZvuU=; b=C6qfue45qy5nxbXpE1MFh0F/hZiRZSqskeTvUJaiXF4F/wtwIEk4aj1WskKl10f7xD agP/yOYNG2xXufo/shtdPlfFAv1PdPrCUuMIrZl4ywtj3cPqlKpEGvBW5WzVQksQw7pH b6rXMOo95yk2MG3e9iyxUUT820XM5kukGOwkotJ0fowH5d172Uyq2bE23aTZoFrUWX/K vF3Y3eXzIugGHlBQ2jcS1LhMmqMCp2fVjBKU3uIYFFH729jKIVGId+kMSZpkrAQwCCDX XRCOkBARSRBvbDP1Qjdhmcwpq0Tks1nlS8L3QyNQAS3blWfd4L1iRTBdh3yL7G9/oIoD xucw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id on13-20020a17090b1d0d00b001c6d5497bb9si17973765pjb.28.2022.04.12.23.29.44; Tue, 12 Apr 2022 23:30:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232318AbiDMFCX (ORCPT + 99 others); Wed, 13 Apr 2022 01:02:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229539AbiDMFCW (ORCPT ); Wed, 13 Apr 2022 01:02:22 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D77225E1 for ; Tue, 12 Apr 2022 22:00:02 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 6C12F68B05; Wed, 13 Apr 2022 06:59:58 +0200 (CEST) Date: Wed, 13 Apr 2022 06:59:58 +0200 From: Christoph Hellwig To: Chao Gao Cc: Robin Murphy , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, m.szyprowski@samsung.com, hch@lst.de, Wang Zhaoyang1 , Gao Liang , Kevin Tian Subject: Re: [PATCH] dma-direct: avoid redundant memory sync for swiotlb Message-ID: <20220413045958.GA31209@lst.de> References: <20220412113805.3210-1-chao.gao@intel.com> <20220413010157.GA10502@gao-cwp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220413010157.GA10502@gao-cwp> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 13, 2022 at 09:02:02AM +0800, Chao Gao wrote: > dma_direct_sync_single_for_cpu() also calls arch_sync_dma_for_cpu_all() > and arch_dma_mark_clean() in some cases. if SWIOTLB does sync internally, > should these two functions be called by SWIOTLB? > > Personally, it might be better if swiotlb can just focus on bounce buffer > alloc/free. Adding more DMA coherence logic into swiotlb will make it > a little complicated. > > How about an open-coded version of dma_direct_sync_single_for_cpu > in dma_direct_unmap_page with swiotlb_sync_single_for_cpu replaced by > swiotlb_tbl_unmap_single? I don't think the swiotlb and non-coherent case ever fully worked. Before the merge of swiotlb into dma-direct they obviously were mutally exclusive, and even now all the cache maintainance is done on the physical address of the original data, not the swiotlb buffer. If we want to fix that properly all the arch dma calls will need to move into swiotlb, but that is a much bigger patch. So for now I'd be happy with the one liner presented here, but eventually the whole area could use an overhaul.