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 63FEFC433EF for ; Tue, 28 Jun 2022 12:18:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345466AbiF1MS0 (ORCPT ); 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 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