From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D8B323A4 for ; Sat, 30 Jul 2022 06:23:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659162201; x=1690698201; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=jJgGhh4GtN+6tyytNQDWb6gnYAcLWIHEmVqW7XXkpeQ=; b=ma+U2lzsaG2U04yvroMTSdTUrLVsjsBcQoXTe1XhOJQREAfqITqAox4X CkSfKKDU0OsPTQRG2XxmKW88oVBxaT0zRPb3kc/uv93qQNPNDeVVxkCA/ Dhl98+hYFO4iMZFSaeb5+OTk42EKcxBtU4UbBZeUuYSIuNDK2IR8VU98s Wtzbg8iUTRWH2Odc/cLE1dwQwUQFxgoyZVxecK+oXOysTrEtVGfT/N5uk z0MF83S/V3uzX41PB5jbLNf72r2vrNWYYFl7G2UZBET7/z05V+/gcesya 090w+6PqddpQQgxeYDHxopJN/bejAC183DT/b5DzyC7W0ctaIi8Y4xRuc g==; X-IronPort-AV: E=McAfee;i="6400,9594,10423"; a="287652190" X-IronPort-AV: E=Sophos;i="5.93,203,1654585200"; d="scan'208";a="287652190" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2022 23:23:20 -0700 X-IronPort-AV: E=Sophos;i="5.93,203,1654585200"; d="scan'208";a="660517319" Received: from blu2-mobl3.ccr.corp.intel.com (HELO [10.254.210.174]) ([10.254.210.174]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2022 23:23:16 -0700 Message-ID: Date: Sat, 30 Jul 2022 14:23:15 +0800 Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Cc: baolu.lu@linux.intel.com, Joerg Roedel , Christoph Hellwig , "Raj, Ashok" , Will Deacon , Robin Murphy , Jean-Philippe Brucker , "Jiang, Dave" , Vinod Koul , Eric Auger , "Liu, Yi L" , "Pan, Jacob jun" , Zhangfei Gao , "Zhu, Tony" , "iommu@lists.linux.dev" , "linux-kernel@vger.kernel.org" , Jean-Philippe Brucker Subject: Re: [PATCH v10 04/12] iommu: Add attach/detach_dev_pasid iommu interface Content-Language: en-US To: Jason Gunthorpe , "Tian, Kevin" References: <20220723141118.GD79279@nvidia.com> <686b137f-232a-2a78-beb0-e4373bd20959@linux.intel.com> <20220725144005.GE3747@nvidia.com> <6da27a6b-b580-4ba4-24c8-ebdfb2d9345d@linux.intel.com> <20220726135722.GC4438@nvidia.com> <20220727115339.GM4438@nvidia.com> From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2022/7/29 20:22, Jason Gunthorpe wrote: > The RID issue is that we can't reliably tell the source apart in a > group - so all the RIDs in a group have to be considered as the same > RID, and mapped to the same PASID table. > > But that is the only restriction of a group we have left, because the > 'iommu doesn't isolate all traffic' restriction is defined not to > exist if PASID is supported. Get you. Thank you for the guide. > >> So yes, from this angle leaving one table per group is a simpler >> thing to do, especially when it's unclear whether there is real >> demand to enable PASID for multi-device group. 😊 > Except it is confusing, complicated and unnecessary. Treating PASID of > multi-device groups the same as everything else is logically simple. Yes. Considering that current PASID use cases occur only on singleton groups, to make things simple, let's start our PASID attachment support simply from singleton groups. Best regards, baolu