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;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jean-Philippe Brucker <jean-philippe@linaro.org>
CC:     Lu Baolu <baolu.lu@linux.intel.com>,
        Joerg Roedel <joro@8bytes.org>,
        Jason Gunthorpe <jgg@nvidia.com>,
        Christoph Hellwig <hch@infradead.org>,
        "Raj, Ashok" <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
        "Robin Murphy" <robin.murphy@arm.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        Vinod Koul <vkoul@kernel.org>,
        Eric Auger <eric.auger@redhat.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "Pan, Jacob jun" <jacob.jun.pan@intel.com>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v7 06/10] iommu/sva: Refactoring
 iommu_sva_bind/unbind_device()
Thread-Topic: [PATCH v7 06/10] iommu/sva: Refactoring
 iommu_sva_bind/unbind_device()
Thread-Index: AQHYa1GHkRXh3WJ3kEuCY8op0Mm4AK0t2DnwgAALZoCAAPxJwIAAW+OAgAyFD4A=
Date:   Thu, 2 Jun 2022 06:46:02 +0000
Message-ID: <BN9PR11MB52763F2C27F567A01003F1878CDE9@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20220519072047.2996983-1-baolu.lu@linux.intel.com>
 <20220519072047.2996983-7-baolu.lu@linux.intel.com>
 <BN9PR11MB5276E462E3B32DDE54DD66418CD79@BN9PR11MB5276.namprd11.prod.outlook.com>
 <Yoy6NxroLLZup0sE@myrica>
 <BN9PR11MB5276FF0D52CF82942CB84D608CD69@BN9PR11MB5276.namprd11.prod.outlook.com>
 <Yo3a7U9kSaSzagkX@myrica>
In-Reply-To: <Yo3a7U9kSaSzagkX@myrica>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CZ99JuRLZ+jQtXP/zYMoZIMvf+8fUwag+CELYXlPTF5/YzhhwrtPvjyZAvRw?=
 =?us-ascii?Q?2rUpgXIKKcUBW07Kc8j0oko7nWdT+MAMgGHRbGEs/PNgm82OF+weHhAo+/of?=
 =?us-ascii?Q?zNVTGEY+yX1wc7R/EIJnrqVPUUXQtAKX7EfBhjj+bzaUAZd4udAMpXpb3No2?=
 =?us-ascii?Q?Z8zWDOYQlsqjNw/xdURTSSZleSS8xCHD4jMpqpFUxj+fuu0TgcyAEgh8l6EB?=
 =?us-ascii?Q?pUNylwrkR278ItF21Xj5eq6QR02nSxFQLLfCd3fBo1yFvsLrq9YO8wNvtQ8G?=
 =?us-ascii?Q?dF8JUBRYDad2Qk6lxrSfbwkDgmLFC8Tn4aJcnC1Jh+Lt5D1N4jbPmQ/NJRvG?=
 =?us-ascii?Q?UAGGhK/k78abGXLII+LFiBFoBPcW3EQRpTmrBaAptPn4Jg/WmbVjOFEUx/Ag?=
 =?us-ascii?Q?LTW/+rx6Q9TAUclEE26ZrvOBE7yI62lgJLLKvJZCIXjnKqQKSGGy7CXZ58rH?=
 =?us-ascii?Q?2HByDX4U9IGclmc8EhFBEvF+CsYjkdwCLpqB5KW9Hl+dT82mDJAV/WfB4sWf?=
 =?us-ascii?Q?hgV6fHMtPG82HJnNC+Dzpw428iMkbJhZhOTy5r9UypHRRSReykvu+5MS6UQs?=
 =?us-ascii?Q?MXGlZYQndMgs0a2pzW4NYAQkyfEbfl+dsnzOwB+SMfWqRQqWVUe3oxlJiClo?=
 =?us-ascii?Q?/kDCYiemj5vUcc3jstiy1tMspDCjgqwopbswIqMFoAq54glSoh8nNuFOfiHv?=
 =?us-ascii?Q?SEylaFg8SFit6m8edAKQ0Sfnhi6nTjywcLbQvLcAwbvKe9Wnbn3q4ts3aNfp?=
 =?us-ascii?Q?cM62ml0fZgbulnVSv+/JshLW/lLBAcTh2o/AbJptL27DEwLdpFtMIf1No9eH?=
 =?us-ascii?Q?09+yzHmPPmHlxcCYLHL6ZMVKWpfxBWMsMBOgb/Yz5i0NG5QygcnBwYWE2fnY?=
 =?us-ascii?Q?xTC53fBpg9WZ5Xkqqp+8lygWYgiYPbVUvEoLSZ4m66AXQKsUpcRlQYLIvqxP?=
 =?us-ascii?Q?a0g96+Hphz8pc87307NGxmGa3NBSCc0+/Q6E0WpUUh55gOYiEtqDVNcPIZbH?=
 =?us-ascii?Q?Y7XxswU7kF80jTE9vUxwHFYYks7rwq76ivsump5ZjpktkgoMsJR3UdHZs8FR?=
 =?us-ascii?Q?JQTvh2GWRa1u6NvsFabXvpWTIJHapWllHCRVWckWuWN4IYaqp4rka5KDH+f1?=
 =?us-ascii?Q?mC6LvLEDAbAUSsDSAU/QSHlA9efx8R3FSn3vKarvRq9gj17bbf9F3mKDx213?=
 =?us-ascii?Q?PbfDOaePLn5AJRivxNxO/9kfUX6m2wqb9/QOcCBDwNej7WFFUgHLkKfOuBf+?=
 =?us-ascii?Q?cBWt7aMAJIVSuWVGO2D5AF6yix383YBUY2CIsQtjn1jFXOqOr71XA6v1Td0U?=
 =?us-ascii?Q?ULz1hyxqnFM9kPfkD6xBUez7T1XrzX959oaIL5uhw0giSbST69dB8/NN/6wv?=
 =?us-ascii?Q?SVJ+chWITxrQtDjs1CiBFlkSwnyjn+nSK1sd40WpZhnBwGGRzoj4P6tcK42a?=
 =?us-ascii?Q?iEFgvprvbGxbFO4Ki2zbkbIQa+X7r0TPqYpXvtQQp1nWsWJgtYfezy7nnRRx?=
 =?us-ascii?Q?BV/nIBmdWv4V0o0QfIaKWqOgBTL/twR2dbGi2p/hYW20auwrioFNUIsgoOu6?=
 =?us-ascii?Q?+htxr+Zh/Jl674mJLRhPFOoxjlVs2JsY/vOnlRS5qu6jDwjlK4SMsw/lFlJb?=
 =?us-ascii?Q?rikyeM7SHc37VPPvFQvNv73aZRkw7xjloJy60kyCSO1JlloTWc7+2Cal96/n?=
 =?us-ascii?Q?VmAIM7zdO+3lwJU5J/85/NsnxypXNc0zhm2NUYYc+VU72eX25VCMiRMZ/rCf?=
 =?us-ascii?Q?9f9KNxrVsA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d7556fa6-8963-471f-4610-08da44638f36
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2022 06:46:02.0872
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dtN8cG0jLlOKpAJhpkNu83jL/TfGQJ+PIrZX0PtcSdt1vc1ZgyU9HP0IMbLb4lNwhClE5UGmqAhVDYPaZpp4kg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2907
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Sent: Wednesday, May 25, 2022 3:30 PM
>=20
> On Wed, May 25, 2022 at 02:04:49AM +0000, Tian, Kevin wrote:
> > > From: Jean-Philippe Brucker <jean-philippe@linaro.org>
> > > Sent: Tuesday, May 24, 2022 6:58 PM
> > >
> > > On Tue, May 24, 2022 at 10:22:28AM +0000, Tian, Kevin wrote:
> > > > > From: Lu Baolu <baolu.lu@linux.intel.com>
> > > > > Sent: Thursday, May 19, 2022 3:21 PM
> > > > >
> > > > > The existing iommu SVA interfaces are implemented by calling the =
SVA
> > > > > specific iommu ops provided by the IOMMU drivers. There's no need
> for
> > > > > any SVA specific ops in iommu_ops vector anymore as we can achiev=
e
> > > > > this through the generic attach/detach_dev_pasid domain ops.
> > > >
> > > > set/block_pasid_dev, to be consistent.
> > > >
> > > > > +
> > > > > +	mutex_lock(&iommu_sva_lock);
> > > > > +	/* Search for an existing domain. */
> > > > > +	domain =3D iommu_get_domain_for_dev_pasid(dev, mm-
> >pasid);
> > > > > +	if (domain) {
> > > > > +		sva_domain =3D to_sva_domain(domain);
> > > > > +		refcount_inc(&sva_domain->bond.users);
> > > > > +		goto out_success;
> > > > > +	}
> > > > > +
> > > >
> > > > why would one device/pasid be bound to a mm more than once?
> > >
> > > Device drivers can call bind() multiple times for the same device and=
 mm,
> > > for example if one process wants to open multiple accelerator queues.
> > >
> >
> > Is it clearer to have a sva_bond_get/put() pair instead of calling
> > bind() multiple times here?
>=20
> I don't think it's clearer, and it would force device drivers to keep
> track of {dev, mm} pairs, when the IOMMU subsystem already does that.
> At the moment a device driver calls
>=20
> 	bond =3D iommu_sva_bind_device(dev, mm)
>=20
> for each ADI that it wants to assign to userspace. If a process happens t=
o
> want multiple ADIs on one device, then the {dev, mm} parameters are the
> same and bind() returns the same bond. Since the IOMMU driver needs to
> track these anyway, it might as well refcount them.
>=20

My impression was that when an interface returns an object
then further reference to this object is usually directly acquired
on the object hence requires the caller to track it. But not a
strong opinion here if others all agree to favor simplicity for
the caller side.

Thanks
Kevin