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 8D881C28CF5 for ; Wed, 26 Jan 2022 14:00:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241867AbiAZOAM (ORCPT ); Wed, 26 Jan 2022 09:00:12 -0500 Received: from foss.arm.com ([217.140.110.172]:41768 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241824AbiAZOAL (ORCPT ); Wed, 26 Jan 2022 09:00:11 -0500 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 E57741FB; Wed, 26 Jan 2022 06:00:10 -0800 (PST) Received: from [10.57.68.47] (unknown [10.57.68.47]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EF8953F793; Wed, 26 Jan 2022 06:00:07 -0800 (PST) Message-ID: Date: Wed, 26 Jan 2022 14:00:03 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH 0/7] iommu cleanup and refactoring Content-Language: en-GB To: Jason Gunthorpe , Lu Baolu Cc: "Tian, Kevin" , "Raj, Ashok" , David Airlie , Will Deacon , "iommu@lists.linux-foundation.org" , Jonathan Hunter , Christoph Hellwig , Alex Williamson , Thierry Reding , Ben Skeggs , Daniel Vetter , "linux-kernel@vger.kernel.org" , "Pan, Jacob jun" References: <20220124071103.2097118-1-baolu.lu@linux.intel.com> <20220124174404.GG966497@nvidia.com> <7febcba4-f5bf-6bf6-6180-895b18d1b806@arm.com> <20220125151602.GL84788@nvidia.com> <20220126132731.GR84788@nvidia.com> From: Robin Murphy In-Reply-To: <20220126132731.GR84788@nvidia.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 2022-01-26 13:27, Jason Gunthorpe via iommu wrote: > On Wed, Jan 26, 2022 at 09:51:36AM +0800, Lu Baolu wrote: > >>>> they are fundamentally different things in their own right, and the ideal >>>> API should give us the orthogonality to also bind a device to an SVA domain >>>> without PASID (e.g. for KVM stage 2, or userspace assignment of simpler >>>> fault/stall-tolerant devices), or attach PASIDs to regular iommu_domains. >>> >>> Yes, these are orthogonal things. A iommu driver that supports PASID >>> ideally should support PASID enabled attach/detatch for every >>> iommu_domain type it supports. >>> >>> SVA should not be entangled with PASID beyond that SVA is often used >>> with PASID - a SVA iommu_domain should be fully usable with a RID too. >> >> The prototype of PASID enabled attach/detach ops could look like: >> >> int (*attach_dev_pasid)(struct iommu_domain *domain, >> struct device *dev, ioasid_t id); >> void (*detach_dev_pasid)(struct iommu_domain *domain, >> struct device *dev, ioasid_t id); > > It seems reasonable and straightforward to me.. > > These would be domain ops? > >> But the iommu driver should implement different callbacks for >> >> 1) attaching an IOMMU DMA domain to a PASID on device; >> - kernel DMA with PASID >> - mdev-like device passthrough >> - etc. >> 2) attaching a CPU-shared domain to a PASID on device; >> - SVA >> - guest PASID >> - etc. > > But this you mean domain->ops would be different? Seems fine, up to > the driver. Indeed, it makes little practical difference whether the driver provides distinct sets of ops or just common callbacks which switch on the domain type internally. I expect that's largely going to come down to personal preference and how much internal driver code is common between the paths. > I'd hope to see some flow like: > > domain = device->bus->iommu_ops->alloc_sva_domain(dev) > domain->ops->attach_dev_pasid(domain, dev, current->pasid) > > To duplicate the current SVA APIs +1 - I'd concur that attach/detach belong as domain ops in general. There's quite a nice logical split forming here where domain ops are the ones that make sense for external subsystems and endpoint drivers to use too, while device ops, with the sole exception of domain_alloc, are IOMMU API internals. By that reasoning, attach/bind/etc. are firmly in the former category. Thanks, Robin.