Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp723727imn; Fri, 29 Jul 2022 23:52:11 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vZVNHwkwmHbanEp0/ab5WM2rCnliBFk85nOHFsDYLxm+YCcmt+J6IJboMTN5qTkntS9Cqy X-Received: by 2002:a62:1687:0:b0:50d:3364:46d4 with SMTP id 129-20020a621687000000b0050d336446d4mr6791448pfw.74.1659163931368; Fri, 29 Jul 2022 23:52:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659163931; cv=none; d=google.com; s=arc-20160816; b=km65+GiAAJaa3Y+kmQ2GRW3w2NAlQfRE0pswhPrSNcvF7JxkB7/ULsqnDIFF6UxLly ATgjqwgoQNJaqTXB8w1wqoKUYILkspxQW36Rl993cgI0HpHCyPGwl0hH2Bd6fcm3oQav BuR3sZyUhRys8o6POkDiTg0S4qzfVI5xtT807TjbyK2RdoW2bWN0pnQK/odNOLqt213b x8we8F/PabiyZyMlaD1B+FaMdx9jyitzPO8SyWbI4PwXV6ZsIC8kIbTcOnz0vChkTB2X IxDfxaoQPVKJOv+Gz37zZnl21FCii1B4vyfHzQ9zq56XvoQxLpD13TelLHLKz4e7ixeW Rbfg== 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=3Zs+MQGVS1YBnHVqvTYxrF5KhQfgzk7BoBd/3YShFLE=; b=m3fb53vq0h5iEdrbZFdFZF6DzkHuFdnggJ0MAwdvXDK+J2zy5Al498v/pYpGtb+QSK W6K+EczbRbxYxpqH2v2JXytCGhADZLo0GSfZJGHXBq5Yv/dBXD/bFP+Jkocl8QmzyIbZ Xcu6vjWF10+HD4ydxOcGNH3v5O880r7dPBXIzJR6sXVkWi/tE6cvRNQNtA006Ks6XtjD VvbNXJRMONzQneikm0EslodkLbLgI3laaoPn2TX50xkNm4kwHQdCWmRjKpCPQ156i4U3 JkiZpnRpLpmbMXSJuSeEyEi2rj6Q2zlJlJ8PsY0KITJo15qlJs4bGSAuzTWR78FVf99o ilJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ma+U2lzs; 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 t4-20020a17090340c400b0016be6146f7fsi5821457pld.192.2022.07.29.23.51.56; Fri, 29 Jul 2022 23:52:11 -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=ma+U2lzs; 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 S230461AbiG3GXX (ORCPT + 99 others); Sat, 30 Jul 2022 02:23:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229534AbiG3GXW (ORCPT ); Sat, 30 Jul 2022 02:23:22 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B20343E45 for ; Fri, 29 Jul 2022 23:23:21 -0700 (PDT) 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="289664853" X-IronPort-AV: E=Sophos;i="5.93,203,1654585200"; d="scan'208";a="289664853" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.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 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 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE 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/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