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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 579F9C433ED for ; Mon, 19 Apr 2021 13:35:26 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B1BD06101C for ; Mon, 19 Apr 2021 13:35:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1BD06101C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:To:Cc:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Hu9W4ZVCMp38AGfdgf7F7LSPt79aslezjplw/JA9Dpg=; b=b1MaTYxH9d+7w9adeq4dqgCsA Oqp7HwM5W73Bt1twX9IyiNUb6IP1jILJP2byc4ZAkM5a3Nb+HufrwulNUEDl5H4q6s4HDp7ilF+Gd FYihSyrQ1cUDQoR/OHTCMrQfbQNGDK+Q85+MyxKumTWnsZRf7J2hpZx4IYJ0mT8AZ1XbE1vPn7/zu hKn5P/nGW/L8P7S/5Uz2qwutvbgHZLGv1pAyoLWS1HCXhW3AIFxnnKnLixGPCqKCn3e1hMTTJsp8c EhoXytpESJqFsFaDCV9tUJhYtib3wybnI0EonT7VU/ussN6/UbYBYo/zz6+ZL7f19JYueab9lD6Id qU5Yed93g==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYU2O-009zbB-5k; Mon, 19 Apr 2021 13:34:04 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYU2J-009zao-5H for linux-arm-kernel@desiato.infradead.org; Mon, 19 Apr 2021 13:34:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References :To:Cc:Sender:Reply-To:Content-ID:Content-Description; bh=CI74qH9jlUkBzBoKz0gAPjasFcn8bNq9W2zBzn/rjMw=; b=GAcmptjCoLznIqLw+B5OpwF+TE 8VWXHaNeZnmGmXLbydAMCk/6oR38Q5R4uF55Ejsn1TP6G/MHjYvE2+fToFJNv+F4EeJVkjQsgM13H 8Ao1wjvDLO7GO0hi8htfrMh/DKJNMuhnhvbYJSu/Ji4Cfqq6eceS//nDTGlwrp4VrZhME4rU1yzJ0 7PPF/zu93xj6gVCrJmIlJctjWjMR6J+S3OY+OrVNu0n3+d8SaShUXFXbUpqLWmNjv39aRVMI07GPD gqvpH89bH1e9cZKVVnHAYdeyR77Fd43AUP2YpJdgtdY+RpkjJAH3TRr0vzG4sHKpt3sgDOA2GdeUZ Fphm+qpw==; Received: from mga14.intel.com ([192.55.52.115]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYU2G-00BPDG-Pm for linux-arm-kernel@lists.infradead.org; Mon, 19 Apr 2021 13:33:57 +0000 IronPort-SDR: f2JBO09rPRvrAiM0vRtYOQHhzzaghAiYEpJVnbkPiuW6YTn9ndrwq7kBO2LgI95pa+joM/sXGr 6xneu5/zTKDg== X-IronPort-AV: E=McAfee;i="6200,9189,9959"; a="194885496" X-IronPort-AV: E=Sophos;i="5.82,234,1613462400"; d="scan'208";a="194885496" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2021 06:33:55 -0700 IronPort-SDR: 0i+wEhGbCQP8Avpf0xm0vMRCRN4QY7mcaZHGnZjD6+zAPyurprhJLO6MMtOQfxvnKw4hGQi5iT gQehU6KPWmxA== X-IronPort-AV: E=Sophos;i="5.82,234,1613462400"; d="scan'208";a="426512252" Received: from blu2-mobl3.ccr.corp.intel.com (HELO [10.254.210.121]) ([10.254.210.121]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2021 06:33:51 -0700 Cc: baolu.lu@linux.intel.com, Alex Williamson , Cornelia Huck , Kirti Wankhede , wanghaibin.wang@huawei.com, jiangkunkun@huawei.com, yuzenghui@huawei.com, lushenming@huawei.com To: Keqian Zhu , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, Robin Murphy , Will Deacon , Joerg Roedel , Yi Sun , Jean-Philippe Brucker , Jonathan Cameron , Tian Kevin References: <20210413085457.25400-1-zhukeqian1@huawei.com> <20210413085457.25400-3-zhukeqian1@huawei.com> <491da550-dc54-42e6-ac91-13d411575fad@huawei.com> From: Lu Baolu Subject: Re: [PATCH v3 02/12] iommu: Add iommu_split_block interface Message-ID: Date: Mon, 19 Apr 2021 21:33:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <491da550-dc54-42e6-ac91-13d411575fad@huawei.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210419_063356_869649_A4985740 X-CRM114-Status: GOOD ( 19.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Keqian, On 2021/4/19 17:32, Keqian Zhu wrote: >>> +EXPORT_SYMBOL_GPL(iommu_split_block); >> Do you really have any consumers of this interface other than the dirty >> bit tracking? If not, I don't suggest to make this as a generic IOMMU >> interface. >> >> There is an implicit requirement for such interfaces. The >> iommu_map/unmap(iova, size) shouldn't be called at the same time. >> Currently there's no such sanity check in the iommu core. A poorly >> written driver could mess up the kernel by misusing this interface. > Yes, I don't think up a scenario except dirty tracking. > > Indeed, we'd better not make them as a generic interface. > > Do you have any suggestion that underlying iommu drivers can share these code but > not make it as a generic iommu interface? > > I have a not so good idea. Make the "split" interfaces as a static function, and > transfer the function pointer to start_dirty_log. But it looks weird and inflexible. I understand splitting/merging super pages is an optimization, but not a functional requirement. So is it possible to let the vendor iommu driver decide whether splitting super pages when starting dirty bit tracking and the opposite operation during when stopping it? The requirement for upper layer is that starting/stopping dirty bit tracking and mapping/unmapping are mutually exclusive. > > On the other hand, if a driver calls map/unmap with split/merge at the same time, > it's a bug of driver, it should follow the rule. > Best regards, baolu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel