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,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 9BC94C433B4 for ; Tue, 20 Apr 2021 01:27:52 +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 E9237613AB for ; Tue, 20 Apr 2021 01:27:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E9237613AB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.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-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From:CC: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=c1N6ZAG3lxsD4nldfl70IFQJsD56/7sw3uaFbKfc7Bo=; b=QwEpmwZo5MjJTasfZ5Dlzy7NF NRN5YAANRLC9cED6inQQ43F3vYjAiWQsZTlkNfAnX/STvHDI7IGowYBj9WuN5n5B3UFspdJWiktHE CanooKpj+79Gl1N9ry0JfBxqNVbyIhctUP/4IDm/hPdyAEgmLQctDn9UrY4BfzWaMgwkjL6cIjSLb uO9ZD+xMLQtNvuHral+WLULbVm5BJRxqmTMVexxyJuIde0ET9U3k60aYiFPmsSWcP0vEscln0d9/5 yqAxdlcE8H0IJ5/gS9xkpjZBiCvTXT2hMwViywZOUsVH089qK5h8wWlXkIZnNJNC4mNAIM2Itb9Im gQK3trfdg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYf9Y-00AviB-Ul; Tue, 20 Apr 2021 01:26:13 +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 1lYf9V-00Avh8-VB for linux-arm-kernel@desiato.infradead.org; Tue, 20 Apr 2021 01:26:10 +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:From:CC:References:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=+yZfCmaufFEe7a7WyoeXucqCgamRYHN10Mtmd8BU+8g=; b=ynSekFN9ZFsILUAKTugkQVtz4P qb3m6g+ygepsHTBg6lX5eNFNs1bOORSTzCe1lZizx/bp9sAQ2MzIzX9CpIOvRt9toPNkOprUDD+13 7TMsvavmOtAcytqy4P6RW07q8f2myLBRaAAQVoaJxK59ytp9uWb4c1k9W2oBm9nbcnwYjX/OXSsxd wrOGqdeHO852O2QFch/St9NiSx90dmjGNZyQ/p7HA7C15PiZl0L4grKCRSgwxKhkMzranc6MQ0Lc4 zem74u6RnsGfj6uXeE5XVI4UJW7Hgge+Q0j+SYctXU1jq3W4BnGR3FLUG3so54HM2wgkFUD/5qK8b myKqsv7w==; Received: from szxga04-in.huawei.com ([45.249.212.190]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYf9P-00BkxL-WA for linux-arm-kernel@lists.infradead.org; Tue, 20 Apr 2021 01:26:08 +0000 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FPQsw6RDnzmdXJ; Tue, 20 Apr 2021 09:23:00 +0800 (CST) Received: from [10.174.187.224] (10.174.187.224) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.498.0; Tue, 20 Apr 2021 09:25:54 +0800 Subject: Re: [PATCH v3 02/12] iommu: Add iommu_split_block interface To: Lu Baolu , , , , 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> CC: Alex Williamson , Cornelia Huck , Kirti Wankhede , , , , From: Keqian Zhu Message-ID: Date: Tue, 20 Apr 2021 09:25:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.174.187.224] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210419_182604_233285_0A8203D5 X-CRM114-Status: GOOD ( 20.87 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Baolu, On 2021/4/19 21:33, Lu Baolu wrote: > 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 Right. If I understand you correct, actually that is what this series does. We realized split/merge in IOMMU core layer, but don't force vendor driver to use it. The problem is that when we expose these interfaces to vendor IOMMU driver, will also expose them to upper driver. > upper layer is that starting/stopping dirty bit tracking and > mapping/unmapping are mutually exclusive. OK, I will explicitly add the hints. Thanks. Thanks, Keqian > >> >> 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