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 9FB86C001E0 for ; Tue, 1 Aug 2023 08:40:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231721AbjHAIk1 (ORCPT ); Tue, 1 Aug 2023 04:40:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231375AbjHAIkY (ORCPT ); Tue, 1 Aug 2023 04:40:24 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27C1A10EB; Tue, 1 Aug 2023 01:40: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=1690879222; x=1722415222; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=REn/Is4TBVpWaD5oECbSAASATiSAsFC/V8UYQ7o8W6k=; b=XBA79slGsmwlcUUOV09EDNhRW6UgGPRXxQF6hq8vu2P2rYUMxv4yrrV3 1PfrQTWXqWssBZYuPCcKOK1TUxnHPnfvy+2gxb4FWNEUdFTIFOrXPAUX+ C0F4KtlM5pDsWV1/Wooa4PZ7lZK/UBwq/8FXy+KE73MXF573HZKdPZgQD DF5g+VhewxwDbezOvDWT5G/WrmJU6DpjwTZqagLpSRYiI24/3nFWho4m9 jbTtbn9tNRGzl43wmndNgorRaiyCHe/Y3QiG5phyQtxuOp1iCgtxba/0S 0KW63GXzN3+pSLHoiTjrl1W2/w82tLoQLJL8HcHc5lO7vnKuPuPBh650U g==; X-IronPort-AV: E=McAfee;i="6600,9927,10788"; a="366708774" X-IronPort-AV: E=Sophos;i="6.01,246,1684825200"; d="scan'208";a="366708774" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Aug 2023 01:40:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10788"; a="842637504" X-IronPort-AV: E=Sophos;i="6.01,246,1684825200"; d="scan'208";a="842637504" Received: from blu2-mobl.ccr.corp.intel.com (HELO [10.254.213.15]) ([10.254.213.15]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Aug 2023 01:40:18 -0700 Message-ID: Date: Tue, 1 Aug 2023 16:40:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: baolu.lu@linux.intel.com, Yi Liu , Jacob Pan , iommu@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] iommu: Move pasid array from group to device Content-Language: en-US To: "tina.zhang" , Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian , Jean-Philippe Brucker , Nicolin Chen References: <20230801063125.34995-1-baolu.lu@linux.intel.com> <20230801063125.34995-3-baolu.lu@linux.intel.com> <1254d61b-1f4e-2ef3-c3dc-95180f26f08c@intel.com> From: Baolu Lu In-Reply-To: <1254d61b-1f4e-2ef3-c3dc-95180f26f08c@intel.com> 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 2023/8/1 16:07, tina.zhang wrote: > Hi Baolu, Hi Tina, > Although this patch moves the domain reference pointer from a per-group > structure to a per-device structure, the domain life-cycle is still > expected to be managed per-group (i.e., iommu_domain_free() is called in > iommu_group_release()). Is this what we expect? The lifecycle of an iommu domain is independent of the lifecycle of the iommu group that it is attached to. The system domains, such as the default domain and the blocking domain, are allocated and managed by the iommu core. These domains are freed when the group is freed. However, any device driver can allocate its own iommu domains. The device driver can set/remove the domain to/from the RID or PASID of the device. Best regards, baolu