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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 820F7C433EF for ; Fri, 29 Apr 2022 11:19:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358254AbiD2LWi (ORCPT ); Fri, 29 Apr 2022 07:22:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358244AbiD2LWg (ORCPT ); Fri, 29 Apr 2022 07:22:36 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5FFCC8567A for ; Fri, 29 Apr 2022 04:19:17 -0700 (PDT) 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 08D281063; Fri, 29 Apr 2022 04:19:17 -0700 (PDT) Received: from [10.57.80.98] (unknown [10.57.80.98]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BA3103F73B; Fri, 29 Apr 2022 04:19:13 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2022 12:19:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support Content-Language: en-GB To: Joao Martins , "Tian, Kevin" Cc: Joerg Roedel , Suravee Suthikulpanit , Will Deacon , Jean-Philippe Brucker , Keqian Zhu , Shameerali Kolothum Thodi , David Woodhouse , Lu Baolu , Jason Gunthorpe , Nicolin Chen , Yishai Hadas , Eric Auger , "Liu, Yi L" , Alex Williamson , Cornelia Huck , "kvm@vger.kernel.org" , "iommu@lists.linux-foundation.org" References: <20220428210933.3583-1-joao.m.martins@oracle.com> <20220428210933.3583-16-joao.m.martins@oracle.com> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 2022-04-29 12:05, Joao Martins wrote: > On 4/29/22 09:28, Tian, Kevin wrote: >>> From: Joao Martins >>> Sent: Friday, April 29, 2022 5:09 AM >>> >>> Similar to .read_and_clear_dirty() use the page table >>> walker helper functions and set DBM|RDONLY bit, thus >>> switching the IOPTE to writeable-clean. >> >> this should not be one-off if the operation needs to be >> applied to IOPTE. Say a map request comes right after >> set_dirty_tracking() is called. If it's agreed to remove >> the range op then smmu driver should record the tracking >> status internally and then apply the modifier to all the new >> mappings automatically before dirty tracking is disabled. >> Otherwise the same logic needs to be kept in iommufd to >> call set_dirty_tracking_range() explicitly for every new >> iopt_area created within the tracking window. > > Gah, I totally missed that by mistake. New mappings aren't > carrying over the "DBM is set". This needs a new io-pgtable > quirk added post dirty-tracking toggling. > > I can adjust, but I am at odds on including this in a future > iteration given that I can't really test any of this stuff. > Might drop the driver until I have hardware/emulation I can > use (or maybe others can take over this). It was included > for revising the iommu core ops and whether iommufd was > affected by it. > > I'll delete the range op, and let smmu v3 driver walk its > own IO pgtables. TBH I'd be inclined to just enable DBM unconditionally in arm_smmu_domain_finalise() if the SMMU supports it. Trying to toggle it dynamically (especially on a live domain) seems more trouble that it's worth. Robin. 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B2316C433FE for ; Fri, 29 Apr 2022 11:19:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 471B18400F; Fri, 29 Apr 2022 11:19:22 +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 UNUnaQTNhdLx; Fri, 29 Apr 2022 11:19:21 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTPS id 3D58184032; Fri, 29 Apr 2022 11:19:21 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id BF04DC0032; Fri, 29 Apr 2022 11:19:20 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0C704C002D for ; Fri, 29 Apr 2022 11:19:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id E784560E9E for ; Fri, 29 Apr 2022 11:19:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE5eUGOvw4ee for ; Fri, 29 Apr 2022 11:19:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp3.osuosl.org (Postfix) with ESMTP id 2C7E860E2F for ; Fri, 29 Apr 2022 11:19:18 +0000 (UTC) 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 08D281063; Fri, 29 Apr 2022 04:19:17 -0700 (PDT) Received: from [10.57.80.98] (unknown [10.57.80.98]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BA3103F73B; Fri, 29 Apr 2022 04:19:13 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2022 12:19:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH RFC 15/19] iommu/arm-smmu-v3: Add set_dirty_tracking_range() support Content-Language: en-GB To: Joao Martins , "Tian, Kevin" References: <20220428210933.3583-1-joao.m.martins@oracle.com> <20220428210933.3583-16-joao.m.martins@oracle.com> From: Robin Murphy In-Reply-To: Cc: Jean-Philippe Brucker , Yishai Hadas , Jason Gunthorpe , "kvm@vger.kernel.org" , Cornelia Huck , "iommu@lists.linux-foundation.org" , Alex Williamson , Will Deacon , David Woodhouse 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2022-04-29 12:05, Joao Martins wrote: > On 4/29/22 09:28, Tian, Kevin wrote: >>> From: Joao Martins >>> Sent: Friday, April 29, 2022 5:09 AM >>> >>> Similar to .read_and_clear_dirty() use the page table >>> walker helper functions and set DBM|RDONLY bit, thus >>> switching the IOPTE to writeable-clean. >> >> this should not be one-off if the operation needs to be >> applied to IOPTE. Say a map request comes right after >> set_dirty_tracking() is called. If it's agreed to remove >> the range op then smmu driver should record the tracking >> status internally and then apply the modifier to all the new >> mappings automatically before dirty tracking is disabled. >> Otherwise the same logic needs to be kept in iommufd to >> call set_dirty_tracking_range() explicitly for every new >> iopt_area created within the tracking window. > > Gah, I totally missed that by mistake. New mappings aren't > carrying over the "DBM is set". This needs a new io-pgtable > quirk added post dirty-tracking toggling. > > I can adjust, but I am at odds on including this in a future > iteration given that I can't really test any of this stuff. > Might drop the driver until I have hardware/emulation I can > use (or maybe others can take over this). It was included > for revising the iommu core ops and whether iommufd was > affected by it. > > I'll delete the range op, and let smmu v3 driver walk its > own IO pgtables. TBH I'd be inclined to just enable DBM unconditionally in arm_smmu_domain_finalise() if the SMMU supports it. Trying to toggle it dynamically (especially on a live domain) seems more trouble that it's worth. Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu