Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3910559iog; Tue, 28 Jun 2022 05:26:28 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tI0kGPRbZuSdDlKmdhexbcjS/FAILCt/qlGo3EI8BpvaiNOH2Ui29PHu8gkG+/b9nICH59 X-Received: by 2002:a17:906:dc8c:b0:722:f40e:e653 with SMTP id cs12-20020a170906dc8c00b00722f40ee653mr17723284ejc.83.1656419187900; Tue, 28 Jun 2022 05:26:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656419187; cv=none; d=google.com; s=arc-20160816; b=jg/9sDqS/j0k8VpP1N+zblJBCTDQ2/B14DOJNw6IaxjjZC5qwTnC//OP/x7IrCDbUQ ilwPzxzs5otNiBJgt3x1pr7hVSTByajYr/7l20q1n2ohGsnViPXMDrSbrMhF6Jzz7ue2 XknvDghvwm9qDR7PeGBog41lsuusL+PMxlMqTAgVoXJsRoRE0Cjyubg0Ud/ayxx8qsGy YGYRgWjBl01VMysZLzHTATuVHMUse1L2e6DvF5sJDaUy1RkDDPfD1Sntsmduh9g7dvKB 3yxABGUPRf1GX7bBPDBu4umXCwZoTYuj80d32igx9Uu9+VbjA+MyY7pUnC8p2H8OS5Z8 2NgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:cc:user-agent:mime-version :date:message-id:dkim-signature; bh=wc+WiSODHVbHWobXum8JTEVPxtB27jl0NUs/zDM4v4M=; b=p+5fV2b8aM2etAGXuF64Bm72LFVUgqgPv01FJ7R8Ez+b+Wrb8BYQpgfcrfFIc8XmSg PWwK5ksg8QNEBgStzIDKt6Qf7DzYIcuLWErvEYy1sXHhFm2ILUCDlFUmeztTbZ9xDkIG xqPbV9G4WIRNeP9VmPiazN2Uq191r9BvFs11CTFK3LV9INVlnUrU2G+Yg0Z/IxyvsOwN y95BCTDIrEj30/1trVU9nEiNMNXdFMQ6IoGuBhhWcVcbazwmL1VbTDHgn55nRIkFsU6e 2lUSVeeK77Xqakye/EFGoFa1Ubxk6LKCeyzfHM41c+7Bw4KiQBih5RCbkvZTnOQNVboA mcxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=czGrpXVN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ji22-20020a170907981600b006e8bbf3d88fsi17219563ejc.15.2022.06.28.05.26.00; Tue, 28 Jun 2022 05:26:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=czGrpXVN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345526AbiF1MS0 (ORCPT + 99 others); Tue, 28 Jun 2022 08:18:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345481AbiF1MSX (ORCPT ); Tue, 28 Jun 2022 08:18:23 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D62C26550 for ; Tue, 28 Jun 2022 05:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656418702; x=1687954702; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=Xu+W3z9Vfv/K82AHMIeu/0YjAhTvZA+Ccl9JNUx64kI=; b=czGrpXVNwacjY6A3HFyMGIVH64Hw8Pubda4e6YTwUWqvmCVSbLJX/CVv BtDOHEaQhGRU/quLtotcB6pnrn3rNUGOk9foIn5YW60sDBHAZxUxTTuzv pJhuON1Y0CZzXURVflCNeiNoz9SUo2iqz4AkFNgO1qhHkSUeg9POml2sJ roRcWKx4+AHQfpej3MPkreg3ryCtAa3/8Kp36Sv4DeL2wg9m0japTRpvW +FqSQJ4LLL8yxN9W1yvc/AWZADZQl3qifz+mJO8cGMYMzAIM02300tHDL m8SWcb6OioLIjixrvK1+7scYlkoBAKElmBeO8Hyj5WU0i2ndhcSoEKNh7 Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10391"; a="282817041" X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="282817041" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 05:18:21 -0700 X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="646891842" Received: from ltang11-mobl1.ccr.corp.intel.com (HELO [10.249.169.64]) ([10.249.169.64]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 05:18:17 -0700 Message-ID: <826513b6-15d3-902d-03c2-7f7e68a84095@linux.intel.com> Date: Tue, 28 Jun 2022 20:18:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: baolu.lu@linux.intel.com, Joerg Roedel , Jason Gunthorpe , Christoph Hellwig , "Raj, Ashok" , Will Deacon , Robin Murphy , Jean-Philippe Brucker , "Jiang, Dave" , Vinod Koul , Eric Auger , "Liu, Yi L" , "Pan, Jacob jun" , "iommu@lists.linux-foundation.org" , "iommu@lists.linux.dev" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v9 10/11] iommu: Per-domain I/O page fault handling Content-Language: en-US To: "Tian, Kevin" , Jean-Philippe Brucker References: <20220621144353.17547-1-baolu.lu@linux.intel.com> <20220621144353.17547-11-baolu.lu@linux.intel.com> From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/6/28 18:02, Tian, Kevin wrote: >> From: Jean-Philippe Brucker >> Sent: Tuesday, June 28, 2022 5:44 PM >> >> On Tue, Jun 28, 2022 at 08:39:36AM +0000, Tian, Kevin wrote: >>>> From: Lu Baolu >>>> Sent: Tuesday, June 21, 2022 10:44 PM >>>> >>>> Tweak the I/O page fault handling framework to route the page faults to >>>> the domain and call the page fault handler retrieved from the domain. >>>> This makes the I/O page fault handling framework possible to serve more >>>> usage scenarios as long as they have an IOMMU domain and install a >> page >>>> fault handler in it. Some unused functions are also removed to avoid >>>> dead code. >>>> >>>> The iommu_get_domain_for_dev_pasid() which retrieves attached >> domain >>>> for a {device, PASID} pair is used. It will be used by the page fault >>>> handling framework which knows {device, PASID} reported from the >> iommu >>>> driver. We have a guarantee that the SVA domain doesn't go away during >>>> IOPF handling, because unbind() waits for pending faults with >>>> iopf_queue_flush_dev() before freeing the domain. Hence, there's no >> need >>>> to synchronize life cycle of the iommu domains between the unbind() and >>>> the interrupt threads. >>> >>> I found iopf_queue_flush_dev() is only called in intel-iommu driver. Did >>> I overlook anything? >> >> The SMMU driver will need it as well when we upstream PRI support. >> Currently it only supports stall, and that requires the device driver to >> flush all DMA including stalled transactions *before* calling unbind(), so >> ne need for iopf_queue_flush_dev() in this case. >> > > then it makes sense. Probably Baolu can add this information in the > commit msg so others with similar question can quickly get the > point here. Sure. Updated. Best regards, baolu