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 76184C4332F for ; Mon, 14 Feb 2022 15:18:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355746AbiBNPSv (ORCPT ); Mon, 14 Feb 2022 10:18:51 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:45222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231397AbiBNPSr (ORCPT ); Mon, 14 Feb 2022 10:18:47 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 77C40593BC; Mon, 14 Feb 2022 07:18:39 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2E72F1063; Mon, 14 Feb 2022 07:18:39 -0800 (PST) Received: from [10.57.70.89] (unknown [10.57.70.89]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 972823F70D; Mon, 14 Feb 2022 07:18:35 -0800 (PST) Message-ID: <08e90a61-8491-acf1-ab0f-f93f97366d24@arm.com> Date: Mon, 14 Feb 2022 15:18:31 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH v1 3/8] iommu: Extend iommu_at[de]tach_device() for multi-device groups Content-Language: en-GB To: Joerg Roedel , Jason Gunthorpe Cc: Stuart Yoder , rafael@kernel.org, David Airlie , linux-pci@vger.kernel.org, Thierry Reding , Diana Craciun , Dmitry Osipenko , Will Deacon , Ashok Raj , Jonathan Hunter , Christoph Hellwig , Kevin Tian , Chaitanya Kulkarni , Alex Williamson , kvm@vger.kernel.org, Bjorn Helgaas , Dan Williams , Greg Kroah-Hartman , Cornelia Huck , linux-kernel@vger.kernel.org, Li Yang , iommu@lists.linux-foundation.org, Jacob jun Pan , Daniel Vetter References: <20220106022053.2406748-1-baolu.lu@linux.intel.com> <20220106022053.2406748-4-baolu.lu@linux.intel.com> <20220214130313.GV4160@nvidia.com> From: Robin Murphy 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-02-14 14:39, Joerg Roedel wrote: > On Mon, Feb 14, 2022 at 09:03:13AM -0400, Jason Gunthorpe wrote: >> Groups should disappear into an internal implementation detail, not be >> so prominent in the API. > > Not going to happen, IOMMU groups are ABI and todays device assignment > code, including user-space, relies on them. > > Groups implement and important aspect of hardware IOMMUs that the API > can not abstract away: That there are devices which share the same > request-id. > > This is not an issue for devices concerned by iommufd, but for legacy > device assignment it is. The IOMMU-API needs to handle both in a clean > API, even if it means that drivers need to lookup the sub-group of a > device first. > > And I don't see how a per-device API can handle both in a device-centric > way. For sure it is not making it 'device centric but operate on groups > under the hood'. Arguably, iommu_attach_device() could be renamed something like iommu_attach_group_for_dev(), since that's effectively the semantic that all the existing API users want anyway (even VFIO at the high level - the group is the means for the user to assign their GPU/NIC/whatever device to their process, not the end in itself). That's just a lot more churn. It's not that callers should be blind to the entire concept of groups altogether - they remain a significant reason why iommu_attach_device() might fail, for one thing - however what callers really shouldn't need to be bothered with is the exact *implementation* of groups. I do actually quite like the idea of refining the group abstraction into isolation groups as a superset of alias groups, but if anything that's a further argument for not having the guts of the current abstraction exposed in places that don't need to care - otherwise that would be liable to be a microcosm of this series in itself: widespread churn vs. "same name, new meaning" compromises. Robin.