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.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 9E45FC433DB for ; Tue, 9 Feb 2021 12:04:41 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 3A8A064E8C for ; Tue, 9 Feb 2021 12:04:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A8A064E8C 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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=x1sBOkA+4vg/mpthQ8Db5JO9Fdjf8XoNG7+dM7Tp1fE=; b=YxR/LYobUybYXsTGn+/LNFrW1 5R80kxjL1aYKBpPlfO9CCPJ+WI44mrVRkZecU6cqs1wFs5FSd+ZfeD/9uyZYQqzaTttWRh35wrkcg QRlApb9LopQlS99MAR246wzlJ4qB9ekvvsHj5xLgqCVqZFOwBSaKd4ZCEV7quyS40n5NoxfTo3Roh Mz83VmoWE4+gbYmTkhd2J/IcPwmXfmYMeHXth2XHa+xmAwWGp7NldCocFlmTzqNV7EAPvUxb8K/Ec DrGkbrnn5X+TIsaz/bJCT7C5WF5R/phCJFAgAS5yrXLh0VMSJktNAMOkOB/ynVxjmNwYS/mxRuDk/ VJSbI5Hfg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9Rk1-00057J-Hg; Tue, 09 Feb 2021 12:03:37 +0000 Received: from mga09.intel.com ([134.134.136.24]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9Rjy-00056F-IR for linux-arm-kernel@lists.infradead.org; Tue, 09 Feb 2021 12:03:35 +0000 IronPort-SDR: jL7k2xFx8YHrT70JEIFwBO0hVxRIxADMyqLHx6KI4PbFQuCSpNdPVnckImSp04DDe7q9kfEW34 9psDRpN+WNAA== X-IronPort-AV: E=McAfee;i="6000,8403,9889"; a="182012861" X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="182012861" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2021 04:03:16 -0800 IronPort-SDR: 0ieoaeAKU7d3c11pykydksMQ7vj3nDDcGmtrF0t/KBBgWNh9lq8KKHEiw0mCbglS6xKJI2v75a mLYjV2Vco98Q== X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="396093725" Received: from yisun1-ubuntu.bj.intel.com (HELO yi.y.sun) ([10.238.156.116]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA256; 09 Feb 2021 04:03:10 -0800 Date: Tue, 9 Feb 2021 19:57:44 +0800 From: Yi Sun To: Keqian Zhu Subject: Re: [RFC PATCH 10/11] vfio/iommu_type1: Optimize dirty bitmap population based on iommu HWDBM Message-ID: <20210209115744.GB28580@yi.y.sun> References: <20210128151742.18840-1-zhukeqian1@huawei.com> <20210128151742.18840-11-zhukeqian1@huawei.com> <20210207095630.GA28580@yi.y.sun> <407d28db-1f86-8d4f-ab15-3c3ac56bbe7f@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <407d28db-1f86-8d4f-ab15-3c3ac56bbe7f@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210209_070334_893931_C892DB72 X-CRM114-Status: GOOD ( 19.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , kvm@vger.kernel.org, Catalin Marinas , Kirti Wankhede , Will Deacon , kvmarm@lists.cs.columbia.edu, Marc Zyngier , jiangkunkun@huawei.com, yuzenghui@huawei.com, wanghaibin.wang@huawei.com, kevin.tian@intel.com, yan.y.zhao@intel.com, Suzuki K Poulose , Alex Williamson , linux-arm-kernel@lists.infradead.org, Cornelia Huck , linux-kernel@vger.kernel.org, lushenming@huawei.com, iommu@lists.linux-foundation.org, James Morse , Robin Murphy , baolu.lu@linux.intel.com 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 On 21-02-07 18:40:36, Keqian Zhu wrote: > Hi Yi, > > On 2021/2/7 17:56, Yi Sun wrote: > > Hi, > > > > On 21-01-28 23:17:41, Keqian Zhu wrote: > > > > [...] > > > >> +static void vfio_dma_dirty_log_start(struct vfio_iommu *iommu, > >> + struct vfio_dma *dma) > >> +{ > >> + struct vfio_domain *d; > >> + > >> + list_for_each_entry(d, &iommu->domain_list, next) { > >> + /* Go through all domain anyway even if we fail */ > >> + iommu_split_block(d->domain, dma->iova, dma->size); > >> + } > >> +} > > > > This should be a switch to prepare for dirty log start. Per Intel > > Vtd spec, there is SLADE defined in Scalable-Mode PASID Table Entry. > > It enables Accessed/Dirty Flags in second-level paging entries. > > So, a generic iommu interface here is better. For Intel iommu, it > > enables SLADE. For ARM, it splits block. > Indeed, a generic interface name is better. > > The vendor iommu driver plays vendor's specific actions to start dirty log, and Intel iommu and ARM smmu may differ. Besides, we may add more actions in ARM smmu driver in future. > > One question: Though I am not familiar with Intel iommu, I think it also should split block mapping besides enable SLADE. Right? > I am not familiar with ARM smmu. :) So I want to clarify if the block in smmu is big page, e.g. 2M page? Intel Vtd manages the memory per page, 4KB/2MB/1GB. There are two ways to manage dirty pages. 1. Keep default granularity. Just set SLADE to enable the dirty track. 2. Split big page to 4KB to get finer granularity. But question about the second solution is if it can benefit the user space, e.g. live migration. If my understanding about smmu block (i.e. the big page) is correct, have you collected some performance data to prove that the split can improve performance? Thanks! > Thanks, > Keqian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel