Received-SPF: pass (google.com: domain of linux-kernel+bounces-129692-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 3 Apr 2024 08:58:51 -0300
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Nicolin Chen <nicolinc@nvidia.com>, Yi Liu <yi.l.liu@intel.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Joel Granados <j.granados@samsung.com>, iommu@lists.linux.dev,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/9] iommu: Introduce domain attachment handle
Message-ID: <20240403115851.GA1723999@nvidia.com>
References: <20240403011519.78512-1-baolu.lu@linux.intel.com>
 <20240403011519.78512-2-baolu.lu@linux.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240403011519.78512-2-baolu.lu@linux.intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?XliPTdb3JxKu4bdSeMjI5+8cnrWcaAvEAs3FVmf7qpOiLkE6xAeF+nk09pki?=
 =?us-ascii?Q?qmGumr2sK5Uc++MpERC3UeKYzGVdsZGzNP0LzfVF1Y90yU1HfCIZZzWBZcZp?=
 =?us-ascii?Q?Wpvr4Ck+qlGIa24ZScIl2p2ZLJkjuP5e4H6epg0tdWgQdwtz/RICj+Ln2lqg?=
 =?us-ascii?Q?z/3IJv1yR32HQJL3O3dJVR8LlkeApfuYH4LEdtt1xeY5S/xZuXZrlZoU/1sl?=
 =?us-ascii?Q?pSWXJ6ZUdz7HqclgWI9WqZefEhctDi3v8ssUZLCyGErpQfSxIRAFF0kKwyuy?=
 =?us-ascii?Q?Yvxu9zXo7Io1QxFhizCMbeuYpqrPTHatTrXIdJpdJObIYYlufIePmr7bAm4W?=
 =?us-ascii?Q?4iZkr0+8u4uMWBuK/54sAmRif6hBb6q1E32eogkYqO1vgj27s4c0c+TybvLv?=
 =?us-ascii?Q?9iapnBcuhU3itHBmX8X/FxJ0Dpa85vgqxkK1WTKowwe0CA12k6X7C0DqxwI4?=
 =?us-ascii?Q?CX8y0IMEhdwYlF+ncDDm+x0usi3CRPrHckSrB/8jWRa3NaGo+orsXMKtfIRR?=
 =?us-ascii?Q?hliXjMJHAtyfWhIe2C6gWvKYpE7BbuYZBQFORhttUJv5y6lf6AZQqCcKh2AQ?=
 =?us-ascii?Q?YG6tZjiAsim3IO06dhZCO/QvsGZdTpixKQUp0T5OI7fF4lsFlJZ4NQ90t5qT?=
 =?us-ascii?Q?kuW9zJKZWvpH2Qna/oKq0VoNoHnQQ4qAruCJ3uYgPaC6Fhx3dM9cPhe+/ST+?=
 =?us-ascii?Q?8L79beah71p8X+ohb9k9kBqd87v7X5hMSZ8phSQTyoO8g8CgiE8PRKXwqTSj?=
 =?us-ascii?Q?ZpXuDDptr+k61HI88OpB/oM38X9HtdpNFbqF2+nslSOu3TZ4/RsVqEwl8b95?=
 =?us-ascii?Q?DJxPE50Er7rkkKstfQv9/DrOZLgWV5panI0PrX0m/q2Cb0yfbOVKtxzcmiYj?=
 =?us-ascii?Q?rx77KZ/DzExFBh6nqhKU8g+TofcKbIQDr9kYNTxkCC1NvdiQrkSl2pvZFkb6?=
 =?us-ascii?Q?zg+hpM3qEJjILucJNZlK4aHAxN4SoYUKgMd9jRqeA7jI82LQeV1zZ7QUgird?=
 =?us-ascii?Q?IUvuI42sdJq4lJoUN4GpKOmEwLmOWRreziZJS2EgGhceaXnAbppUv/ybPYtG?=
 =?us-ascii?Q?/PSt4uvDlxdapewG50bxyzcBxr6WR1fJ49lIJC8bbS7yVo4lBvdmITjVNK/g?=
 =?us-ascii?Q?ib5UH36t92CgcWdvjDFY+5wPuRNCj4oaGql6YHju7KqDt+Ny5scyaITTZ0E5?=
 =?us-ascii?Q?HawtrA+IQXycT62k1Ta7g3X5NCcSE5LZDmYsJH3bA07eC3nRgG7FYWcKI6+R?=
 =?us-ascii?Q?S42OssTwERxirZtAPXQr29ewiOqyoXLUwGYkFYJ11sTIu8GnBv1gCexvJRYU?=
 =?us-ascii?Q?7bs/XnvzR65JnAR3vp8mkiMdq+9oi+bkyQ5k/RA0B5BrNwkwq32l3f326dM9?=
 =?us-ascii?Q?SAEPb5vru45nYqXe4ZAS8H57AQRIsOdBxSQQsqqio2jv0RbElLDRNjHdutPa?=
 =?us-ascii?Q?4D99MqzKWPOHKzWyllYiABimtQY1BzcsAUkyfPcoGUnZo8kVHzl3hU9bcOnI?=
 =?us-ascii?Q?Jjuk+p38ZUwjQjd1onYufOPtXvXoB0Z//TFijupj/jpnmFAoJsFY9em8xX9Q?=
 =?us-ascii?Q?oT77itEYyg4DeA/n0THjmOibnWD8KgxysInYA0aQ?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: af5f3223-cc13-4bd7-9efe-08dc53d56ee3
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2024 11:58:53.4708
 (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: I55o2z+Sr5WAaDLTY87Qr4urNdfUHcZE+/NdVdiSni6SLBdoB3ZMo8AcCpMidm2h
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB7688

On Wed, Apr 03, 2024 at 09:15:11AM +0800, Lu Baolu wrote:
> Currently, when attaching a domain to a device or its PASID, domain is
> stored within the iommu group. It could be retrieved for use during the
> window between attachment and detachment.
> 
> With new features introduced, there's a need to store more information
> than just a domain pointer. This information essentially represents the
> association between a domain and a device. For example, the SVA code
> already has a custom struct iommu_sva which represents a bond between
> sva domain and a PASID of a device. Looking forward, the IOMMUFD needs
> a place to store the iommufd_device pointer in the core, so that the
> device object ID could be quickly retrieved in the critical fault handling
> path.
> 
> Introduce domain attachment handle that explicitly represents the
> attachment relationship between a domain and a device or its PASID.
> A caller-specific data field can be used by the caller to store additional
> information beyond a domain pointer, depending on its specific use case.
> 
> Co-developed-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> ---
>  drivers/iommu/iommu-priv.h |   9 +++
>  drivers/iommu/iommu.c      | 158 +++++++++++++++++++++++++++++++++----
>  2 files changed, 153 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/iommu/iommu-priv.h b/drivers/iommu/iommu-priv.h
> index 5f731d994803..08c0667cef54 100644
> --- a/drivers/iommu/iommu-priv.h
> +++ b/drivers/iommu/iommu-priv.h
> @@ -28,4 +28,13 @@ void iommu_device_unregister_bus(struct iommu_device *iommu,
>  				 const struct bus_type *bus,
>  				 struct notifier_block *nb);
>  
> +struct iommu_attach_handle {
> +	struct iommu_domain		*domain;
> +	refcount_t			users;

I don't understand how the refcounting can be generally useful. There
is no way to free this:

> +	void				*priv;

When the refcount goes to zero.

Jason