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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 90AC0C19773 for ; Mon, 10 May 2021 12:16:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 73914613C8 for ; Mon, 10 May 2021 12:16:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236061AbhEJMQf (ORCPT ); Mon, 10 May 2021 08:16:35 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:2672 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232250AbhEJLIu (ORCPT ); Mon, 10 May 2021 07:08:50 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FdyrG4tK6z1BKRQ; Mon, 10 May 2021 19:05:02 +0800 (CST) Received: from [10.174.187.224] (10.174.187.224) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.498.0; Mon, 10 May 2021 19:07:34 +0800 Subject: Re: [RFC PATCH v4 01/13] iommu: Introduce dirty log tracking framework To: Lu Baolu , , , , Robin Murphy , Will Deacon , "Joerg Roedel" , Jean-Philippe Brucker , Yi Sun , Tian Kevin References: <20210507102211.8836-1-zhukeqian1@huawei.com> <20210507102211.8836-2-zhukeqian1@huawei.com> <18ac787a-179e-71f7-728b-c43feda80a16@huawei.com> <55fda826-9ab6-a3a0-b17e-a4d4879f00bc@linux.intel.com> CC: Alex Williamson , Kirti Wankhede , Cornelia Huck , Jonathan Cameron , , , , From: Keqian Zhu Message-ID: Date: Mon, 10 May 2021 19:07:33 +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: <55fda826-9ab6-a3a0-b17e-a4d4879f00bc@linux.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.187.224] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Baolu, On 2021/5/10 9:08, Lu Baolu wrote: > Hi Keqian, > > On 5/8/21 3:35 PM, Keqian Zhu wrote: >> Hi Baolu, >> >> On 2021/5/8 11:46, Lu Baolu wrote: >>> Hi Keqian, >>> >>> On 5/7/21 6:21 PM, Keqian Zhu wrote: >>>> Some types of IOMMU are capable of tracking DMA dirty log, such as >>>> ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the >>>> dirty log tracking framework in the IOMMU base layer. >>>> >>>> Four new essential interfaces are added, and we maintaince the status >>>> of dirty log tracking in iommu_domain. >>>> 1. iommu_support_dirty_log: Check whether domain supports dirty log tracking >>>> 2. iommu_switch_dirty_log: Perform actions to start|stop dirty log tracking >>>> 3. iommu_sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap >>>> 4. iommu_clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap >>>> >>>> Note: Don't concurrently call these interfaces with other ops that >>>> access underlying page table. >>>> >>>> Signed-off-by: Keqian Zhu >>>> Signed-off-by: Kunkun Jiang >>>> --- >>>> drivers/iommu/iommu.c | 201 +++++++++++++++++++++++++++++++++++ >>>> include/linux/iommu.h | 63 +++++++++++ >>>> include/trace/events/iommu.h | 63 +++++++++++ >>>> 3 files changed, 327 insertions(+) >>>> >>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c >>>> index 808ab70d5df5..0d15620d1e90 100644 >>>> --- a/drivers/iommu/iommu.c >>>> +++ b/drivers/iommu/iommu.c >>>> @@ -1940,6 +1940,7 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus, >>>> domain->type = type; >>>> /* Assume all sizes by default; the driver may override this later */ >>>> domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; >>>> + mutex_init(&domain->switch_log_lock); >>>> return domain; >>>> } >>>> @@ -2703,6 +2704,206 @@ int iommu_set_pgtable_quirks(struct iommu_domain *domain, >>>> } >>>> EXPORT_SYMBOL_GPL(iommu_set_pgtable_quirks); >>>> +bool iommu_support_dirty_log(struct iommu_domain *domain) >>>> +{ >>>> + const struct iommu_ops *ops = domain->ops; >>>> + >>>> + return ops->support_dirty_log && ops->support_dirty_log(domain); >>>> +} >>>> +EXPORT_SYMBOL_GPL(iommu_support_dirty_log); >>> I suppose this interface is to ask the vendor IOMMU driver to check >>> whether each device/iommu in the domain supports dirty bit tracking. >>> But what will happen if new devices with different tracking capability >>> are added afterward? >> Yep, this is considered in the vfio part. We will query again after attaching or >> detaching devices from the domain. When the domain becomes capable, we enable >> dirty log for it. When it becomes not capable, we disable dirty log for it. > > If that's the case, why not putting this logic in the iommu subsystem so > that it doesn't need to be duplicate in different upper layers? > > For example, add something like dirty_page_trackable in the struct of > iommu_domain and ask the vendor iommu driver to update it once any > device is added/removed to/from the domain. It's also better to disallow If we do it, the upper layer still needs to query the capability from domain and switch dirty log tracking for it. Or do you mean the domain can switch dirty log tracking automatically when its capability change? If so, I think we're lack of some flexibility. The upper layer may have it's own policy, such as only enable dirty log tracking when all domains are capable, and disable dirty log tracking when just one domain is not capable. > any domain attach/detach once the dirty page tracking is on. Yep, this can greatly simplify our code logic, but I don't know whether our maintainers agree that, as they may think that IOMMU dirty logging should not change original domain behaviors. Thanks, Keqian 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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,URIBL_RED,USER_AGENT_SANE_1 autolearn=ham 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 94689C43611 for ; Mon, 10 May 2021 11:07:53 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 B7A6261925 for ; Mon, 10 May 2021 11:07:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B7A6261925 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 6052983BA1; Mon, 10 May 2021 11:07:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz9ppbotO7IX; Mon, 10 May 2021 11:07:50 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTP id B7CE383B9D; Mon, 10 May 2021 11:07:49 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 91118C000E; Mon, 10 May 2021 11:07:49 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id BDD00C0001 for ; Mon, 10 May 2021 11:07:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id AC41283B9D for ; Mon, 10 May 2021 11:07:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob9wLkJiZQi4 for ; Mon, 10 May 2021 11:07:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by smtp1.osuosl.org (Postfix) with ESMTPS id 50E5B83B98 for ; Mon, 10 May 2021 11:07:44 +0000 (UTC) Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FdyrG4tK6z1BKRQ; Mon, 10 May 2021 19:05:02 +0800 (CST) Received: from [10.174.187.224] (10.174.187.224) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.498.0; Mon, 10 May 2021 19:07:34 +0800 Subject: Re: [RFC PATCH v4 01/13] iommu: Introduce dirty log tracking framework To: Lu Baolu , , , , Robin Murphy , Will Deacon , "Joerg Roedel" , Jean-Philippe Brucker , Yi Sun , Tian Kevin References: <20210507102211.8836-1-zhukeqian1@huawei.com> <20210507102211.8836-2-zhukeqian1@huawei.com> <18ac787a-179e-71f7-728b-c43feda80a16@huawei.com> <55fda826-9ab6-a3a0-b17e-a4d4879f00bc@linux.intel.com> From: Keqian Zhu Message-ID: Date: Mon, 10 May 2021 19:07:33 +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: <55fda826-9ab6-a3a0-b17e-a4d4879f00bc@linux.intel.com> X-Originating-IP: [10.174.187.224] X-CFilter-Loop: Reflected Cc: jiangkunkun@huawei.com, Cornelia Huck , Kirti Wankhede , lushenming@huawei.com, Alex Williamson , wanghaibin.wang@huawei.com X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" Hi Baolu, On 2021/5/10 9:08, Lu Baolu wrote: > Hi Keqian, > > On 5/8/21 3:35 PM, Keqian Zhu wrote: >> Hi Baolu, >> >> On 2021/5/8 11:46, Lu Baolu wrote: >>> Hi Keqian, >>> >>> On 5/7/21 6:21 PM, Keqian Zhu wrote: >>>> Some types of IOMMU are capable of tracking DMA dirty log, such as >>>> ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the >>>> dirty log tracking framework in the IOMMU base layer. >>>> >>>> Four new essential interfaces are added, and we maintaince the status >>>> of dirty log tracking in iommu_domain. >>>> 1. iommu_support_dirty_log: Check whether domain supports dirty log tracking >>>> 2. iommu_switch_dirty_log: Perform actions to start|stop dirty log tracking >>>> 3. iommu_sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap >>>> 4. iommu_clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap >>>> >>>> Note: Don't concurrently call these interfaces with other ops that >>>> access underlying page table. >>>> >>>> Signed-off-by: Keqian Zhu >>>> Signed-off-by: Kunkun Jiang >>>> --- >>>> drivers/iommu/iommu.c | 201 +++++++++++++++++++++++++++++++++++ >>>> include/linux/iommu.h | 63 +++++++++++ >>>> include/trace/events/iommu.h | 63 +++++++++++ >>>> 3 files changed, 327 insertions(+) >>>> >>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c >>>> index 808ab70d5df5..0d15620d1e90 100644 >>>> --- a/drivers/iommu/iommu.c >>>> +++ b/drivers/iommu/iommu.c >>>> @@ -1940,6 +1940,7 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus, >>>> domain->type = type; >>>> /* Assume all sizes by default; the driver may override this later */ >>>> domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; >>>> + mutex_init(&domain->switch_log_lock); >>>> return domain; >>>> } >>>> @@ -2703,6 +2704,206 @@ int iommu_set_pgtable_quirks(struct iommu_domain *domain, >>>> } >>>> EXPORT_SYMBOL_GPL(iommu_set_pgtable_quirks); >>>> +bool iommu_support_dirty_log(struct iommu_domain *domain) >>>> +{ >>>> + const struct iommu_ops *ops = domain->ops; >>>> + >>>> + return ops->support_dirty_log && ops->support_dirty_log(domain); >>>> +} >>>> +EXPORT_SYMBOL_GPL(iommu_support_dirty_log); >>> I suppose this interface is to ask the vendor IOMMU driver to check >>> whether each device/iommu in the domain supports dirty bit tracking. >>> But what will happen if new devices with different tracking capability >>> are added afterward? >> Yep, this is considered in the vfio part. We will query again after attaching or >> detaching devices from the domain. When the domain becomes capable, we enable >> dirty log for it. When it becomes not capable, we disable dirty log for it. > > If that's the case, why not putting this logic in the iommu subsystem so > that it doesn't need to be duplicate in different upper layers? > > For example, add something like dirty_page_trackable in the struct of > iommu_domain and ask the vendor iommu driver to update it once any > device is added/removed to/from the domain. It's also better to disallow If we do it, the upper layer still needs to query the capability from domain and switch dirty log tracking for it. Or do you mean the domain can switch dirty log tracking automatically when its capability change? If so, I think we're lack of some flexibility. The upper layer may have it's own policy, such as only enable dirty log tracking when all domains are capable, and disable dirty log tracking when just one domain is not capable. > any domain attach/detach once the dirty page tracking is on. Yep, this can greatly simplify our code logic, but I don't know whether our maintainers agree that, as they may think that IOMMU dirty logging should not change original domain behaviors. Thanks, Keqian _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable 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 80723C43618 for ; Mon, 10 May 2021 11:48:17 +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 E65996121E for ; Mon, 10 May 2021 11:48:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E65996121E 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=fe7/ePMVgZMbSnbrb4HbPIu0hu2k0ffGpg9Ypo7ebas=; b=pSVOlKPDoX4Mp0YUDX8lT6sv+ lBkxglegP9nMfFOUyc/uYkAj+IdOsTey0fZxWL4Qq4xOgUwB/OfK8kTNTwOk6ngGeEYDKgLVE28wr nzO0zFxLoGBxBVeP3zfWtnydGaqD9jJMFELtuL/7XV+DrvcrhvnyYTTHno1I3U9UP6zWa8+Msc3bp GJ0fIPfMAOgYDjYrH3H1IwmwrOoiKLRygRiP50DXnq5xoTcgg5WYReQaq26eg2+T4xOSj0Gg5M2Fa IUY9SihJqNNEoJQA5Ks59zNI/i3umw+8wNkqwWNpPivqOG8I/F0hQgyAlv1E0EFaeL8wqaafoVX6W kuVaDjvsw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lg4Mt-00E8Dr-AK; Mon, 10 May 2021 11:46:36 +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 1lg3lS-00E2MW-VA for linux-arm-kernel@desiato.infradead.org; Mon, 10 May 2021 11:07:56 +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=KKVENceXYYtoXUWMeXkM2GhiG+arRFGrVtzyMjAUaCo=; b=favm4Hx3VAq/MHIXGGqcGc3JyJ k8Ldu/eE0bPwm83fGJhKqBj74x9X58y3CAs/HCPWDZG8k71Dra2oK4A+o6OxlshFlqrwJ1pphmk2C vmxumeJ3w/e5gFfxt9aHxhUu5SlupeVMfE8+bbWEoV+X3hqKyXpzsUOfvD/TK26Xx3phVQjcBRFyq UhA3Boi42q3TRoVQ524HTvtW8zG/WlNZyM++L1LifhH5QdQDBL6WwdETNzEPCYexadrZLHABPDLmE +xMJ7Ddr1gGwd9F/+uJg8un1rt3nFLZt+PLZ5eDe+YZzyQ8oEtl0aexRhySOWN2Pmty47mYcNshjP K8RQ5qVg==; Received: from szxga04-in.huawei.com ([45.249.212.190]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lg3lO-008auV-RU for linux-arm-kernel@lists.infradead.org; Mon, 10 May 2021 11:07:53 +0000 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FdyrG4tK6z1BKRQ; Mon, 10 May 2021 19:05:02 +0800 (CST) Received: from [10.174.187.224] (10.174.187.224) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.498.0; Mon, 10 May 2021 19:07:34 +0800 Subject: Re: [RFC PATCH v4 01/13] iommu: Introduce dirty log tracking framework To: Lu Baolu , , , , Robin Murphy , Will Deacon , "Joerg Roedel" , Jean-Philippe Brucker , Yi Sun , Tian Kevin References: <20210507102211.8836-1-zhukeqian1@huawei.com> <20210507102211.8836-2-zhukeqian1@huawei.com> <18ac787a-179e-71f7-728b-c43feda80a16@huawei.com> <55fda826-9ab6-a3a0-b17e-a4d4879f00bc@linux.intel.com> CC: Alex Williamson , Kirti Wankhede , Cornelia Huck , Jonathan Cameron , , , , From: Keqian Zhu Message-ID: Date: Mon, 10 May 2021 19:07:33 +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: <55fda826-9ab6-a3a0-b17e-a4d4879f00bc@linux.intel.com> 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-20210510_040751_251722_7960BF7B X-CRM114-Status: GOOD ( 20.81 ) 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/5/10 9:08, Lu Baolu wrote: > Hi Keqian, > > On 5/8/21 3:35 PM, Keqian Zhu wrote: >> Hi Baolu, >> >> On 2021/5/8 11:46, Lu Baolu wrote: >>> Hi Keqian, >>> >>> On 5/7/21 6:21 PM, Keqian Zhu wrote: >>>> Some types of IOMMU are capable of tracking DMA dirty log, such as >>>> ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the >>>> dirty log tracking framework in the IOMMU base layer. >>>> >>>> Four new essential interfaces are added, and we maintaince the status >>>> of dirty log tracking in iommu_domain. >>>> 1. iommu_support_dirty_log: Check whether domain supports dirty log tracking >>>> 2. iommu_switch_dirty_log: Perform actions to start|stop dirty log tracking >>>> 3. iommu_sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap >>>> 4. iommu_clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap >>>> >>>> Note: Don't concurrently call these interfaces with other ops that >>>> access underlying page table. >>>> >>>> Signed-off-by: Keqian Zhu >>>> Signed-off-by: Kunkun Jiang >>>> --- >>>> drivers/iommu/iommu.c | 201 +++++++++++++++++++++++++++++++++++ >>>> include/linux/iommu.h | 63 +++++++++++ >>>> include/trace/events/iommu.h | 63 +++++++++++ >>>> 3 files changed, 327 insertions(+) >>>> >>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c >>>> index 808ab70d5df5..0d15620d1e90 100644 >>>> --- a/drivers/iommu/iommu.c >>>> +++ b/drivers/iommu/iommu.c >>>> @@ -1940,6 +1940,7 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus, >>>> domain->type = type; >>>> /* Assume all sizes by default; the driver may override this later */ >>>> domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap; >>>> + mutex_init(&domain->switch_log_lock); >>>> return domain; >>>> } >>>> @@ -2703,6 +2704,206 @@ int iommu_set_pgtable_quirks(struct iommu_domain *domain, >>>> } >>>> EXPORT_SYMBOL_GPL(iommu_set_pgtable_quirks); >>>> +bool iommu_support_dirty_log(struct iommu_domain *domain) >>>> +{ >>>> + const struct iommu_ops *ops = domain->ops; >>>> + >>>> + return ops->support_dirty_log && ops->support_dirty_log(domain); >>>> +} >>>> +EXPORT_SYMBOL_GPL(iommu_support_dirty_log); >>> I suppose this interface is to ask the vendor IOMMU driver to check >>> whether each device/iommu in the domain supports dirty bit tracking. >>> But what will happen if new devices with different tracking capability >>> are added afterward? >> Yep, this is considered in the vfio part. We will query again after attaching or >> detaching devices from the domain. When the domain becomes capable, we enable >> dirty log for it. When it becomes not capable, we disable dirty log for it. > > If that's the case, why not putting this logic in the iommu subsystem so > that it doesn't need to be duplicate in different upper layers? > > For example, add something like dirty_page_trackable in the struct of > iommu_domain and ask the vendor iommu driver to update it once any > device is added/removed to/from the domain. It's also better to disallow If we do it, the upper layer still needs to query the capability from domain and switch dirty log tracking for it. Or do you mean the domain can switch dirty log tracking automatically when its capability change? If so, I think we're lack of some flexibility. The upper layer may have it's own policy, such as only enable dirty log tracking when all domains are capable, and disable dirty log tracking when just one domain is not capable. > any domain attach/detach once the dirty page tracking is on. Yep, this can greatly simplify our code logic, but I don't know whether our maintainers agree that, as they may think that IOMMU dirty logging should not change original domain behaviors. Thanks, Keqian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel