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;
Date:   Wed, 16 Feb 2022 09:54:58 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Lu Baolu <baolu.lu@linux.intel.com>
Cc:     Joerg Roedel <joro@8bytes.org>, Stuart Yoder <stuyoder@gmail.com>,
        rafael@kernel.org, David Airlie <airlied@linux.ie>,
        linux-pci@vger.kernel.org,
        Thierry Reding <thierry.reding@gmail.com>,
        Diana Craciun <diana.craciun@oss.nxp.com>,
        Dmitry Osipenko <digetx@gmail.com>,
        Will Deacon <will@kernel.org>, Ashok Raj <ashok.raj@intel.com>,
        Jonathan Hunter <jonathanh@nvidia.com>,
        Christoph Hellwig <hch@infradead.org>,
        Kevin Tian <kevin.tian@intel.com>,
        Chaitanya Kulkarni <kch@nvidia.com>,
        Alex Williamson <alex.williamson@redhat.com>,
        kvm@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Cornelia Huck <cohuck@redhat.com>,
        linux-kernel@vger.kernel.org, Li Yang <leoyang.li@nxp.com>,
        iommu@lists.linux-foundation.org,
        Jacob jun Pan <jacob.jun.pan@intel.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v1 3/8] iommu: Extend iommu_at[de]tach_device() for
 multi-device groups
Message-ID: <20220216135458.GH4160@nvidia.com>
References: <20220106022053.2406748-1-baolu.lu@linux.intel.com>
 <20220106022053.2406748-4-baolu.lu@linux.intel.com>
 <Ygo/eCRFnraY01WA@8bytes.org>
 <20220214130313.GV4160@nvidia.com>
 <Ygppub+Wjq6mQEAX@8bytes.org>
 <08e90a61-8491-acf1-ab0f-f93f97366d24@arm.com>
 <20220214154626.GF4160@nvidia.com>
 <YgtrJVI9wGMFdPWk@8bytes.org>
 <20220215134744.GO4160@nvidia.com>
 <69f26767-66d6-12df-1754-45ee1932d513@linux.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <69f26767-66d6-12df-1754-45ee1932d513@linux.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?NCk5UuiDLBjp2KBpSna1PT7QVZ/IMrDWVaOjFFG2LmTl5PfTnTLoe5FR5OBt?=
 =?us-ascii?Q?UFmL2eECPJa61zU2enqQqVHbbIQhX0zm74wxQxKw3WPk9M2DHyyBfvd62HiB?=
 =?us-ascii?Q?udvylJoGvS8oICoMCVffkY2ZA1+peimQeDnVyozmgi9kziLRfGnvhV9bz+X3?=
 =?us-ascii?Q?SAoIlslZK8IctTHzbNwefyPBZVuZbxsXpdWj9lCP8XphKieuEHALDwYYK6Fa?=
 =?us-ascii?Q?L7Spopd9ZssfQFtj4hEsnwT8wkvIeLISZNRqSsZSDkUKWsPpvhWFmCNBqx+9?=
 =?us-ascii?Q?BVyHiUCU5XXOaZmQB7H6L4tMrwqHXiNR32feCrB2l9QkJSsLxkxw0q0HnMTk?=
 =?us-ascii?Q?sM8VHpujcBA+7giUZ5jGxlEoPuDCnjTGvDRRbmbZBJ/ZRIcD5xClNHHR2pSD?=
 =?us-ascii?Q?Xdm/EP7lMJ2bONmodSU+Wk+9Mj2rYyi1QvUjBdshzR2zmDeB4Te2DBFMfh34?=
 =?us-ascii?Q?gjyRKDOMYSKhX6JQOBG8F9euyGKPzvNtSD1fskQsXEmG78oz3CdQitzDp1zy?=
 =?us-ascii?Q?2OzaAA2i+bVYUI2cFLNmmh/uNUdghbJ+BjbL0gFkpwfkAjcOGxgGR5NgfD1l?=
 =?us-ascii?Q?4CoXABe0G5coL3btE+C7wD3sNVVwNF2gNTxt2t+H5MM6eeMLDuUW8zBpecPT?=
 =?us-ascii?Q?pcUkKGkwo8f95HicPsp5JRW6hVbljBBlTKVxHibXNwra/HYYC1qB4Zy0MMUU?=
 =?us-ascii?Q?7qvJSHwFCRDOm3yE8YPoh3FvDGc6xEEotwOA/WF8GDvcuKkg2qokiHAPuD0d?=
 =?us-ascii?Q?rFwXsKEb70MqBmUVhCfj4WaKXtP/JGho+VTviFTQHAhTbbO7tr83D6REvwBd?=
 =?us-ascii?Q?jZY3Qar9Rb8ZoB5vaofFcwe6Df775kSKQMy9Pe0wmT5V/2sh0RtYIT9e7NYN?=
 =?us-ascii?Q?l4ZioosE9NU06wAvz4ep/BoSUW5LLztJmzjPnt8rtoTMtDh3JiIOTYjr5laq?=
 =?us-ascii?Q?0zqd+pLRetbKMeMFAJq7o7ySKXrot9EZKtv6Lr7ROq2tetvy1pw32Q/fwwrR?=
 =?us-ascii?Q?dSv5Ll4r019rrXBl3IESigZYt5CWrIPkOi22U5xL0+VQCmHRE/53hwo0xCBR?=
 =?us-ascii?Q?EAXsa2tKNd8JZpynNDFc9RJhhVbJuuRftiQdTw0lpkbVLXytqoADjYDH2F2T?=
 =?us-ascii?Q?J7cKGU5xvRWA97L1nTByR631BbWFgWXFo96Oi5YGV0WsueQ5PpmLf2gC6n66?=
 =?us-ascii?Q?v7AiPYbbsi7SXLMQxAgUk+vVo0SaIPMbKTxWbs8KrkuGBoCYEqxRgnLlSUfD?=
 =?us-ascii?Q?kYKQ8J/NkPH56T8ceiPZYltXV5TmHzrdUQBjdP1FUtCf6mbEzjw8KkMzWLHw?=
 =?us-ascii?Q?BdFDfF3Su+vBjVOVJy51NgCLmJjSu9bY2S5Go279WWXwH4iHeJs3nPRttaS7?=
 =?us-ascii?Q?cWgttau45SUB3NUg+tbZCzcS7ekTJ+iQitcD4aPweqmVjUP28awr4MMZFeKp?=
 =?us-ascii?Q?WpF7iGF7kVzvy2F0+Fmv6qQ5yUKiKRRlKsazidFF+B2hspOR9cXp4sHUPBKh?=
 =?us-ascii?Q?46OUneVl16OwgkQZ1zWvqls6C+MwuWv2PzgXybwjk+oGHsCpp10tv5se9zAd?=
 =?us-ascii?Q?xggIbO1s9nPat//2X3M=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 86d0d7d8-eafd-4da4-1cef-08d9f153ec09
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2022 13:54:59.5797
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 2iPCOqwOn8IEnRqKV2gqIQBGNBIfeNNnNlfIGWxzDU/9KiyrVnqCHZq7sHiHyDDx
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR12MB2640
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Feb 16, 2022 at 02:28:09PM +0800, Lu Baolu wrote:

> It seems everyone agrees that for device assignment (where the I/O
> address is owned by the user-space application), the iommu_group-based
> APIs should always be used. Otherwise, the isolation and protection are
> not guaranteed.

This group/device split is all just driven by VFIO. There is nothing
preventing a struct device * API from being used with user-space, and
Robin has been pushing that way. With enough fixing of VFIO we can do
it.

eg the device-centric VFIO patches should be able to eventually work
entirely on an iommu device API.

> Another proposal (as suggested by Joerg) is to introduce the concept of
> "sub-group". An iommu group could have one or multiple sub-groups with
> non-aliased devices sitting in different sub-groups and use different
> domains.

I still don't see how sub groups help or really change anything here.

The API already has the concept of 'ownership' seperated from the
concept of 'attach a domain to a device'.

Ownership works on the ACS group and attach works on the 'same RID'
group.

The API can take in the struct device and select which internal group
to use based on which action is being done.

Jason