Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
From:   "Zhang, Tina" <tina.zhang@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>
CC:     "Tian, Kevin" <kevin.tian@intel.com>,
        Lu Baolu <baolu.lu@linux.intel.com>,
        Michael Shavit <mshavit@google.com>,
        Vasant Hegde <vasant.hegde@amd.com>,
        "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
Thread-Topic: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
Thread-Index: AQHZ71lrQmeuFVBRWUer3v2RYxTBzrA9INuAgAX9v6A=
Date:   Tue, 10 Oct 2023 13:38:20 +0000
Message-ID: <MW5PR11MB5881879F1B749AB1D4298CC289CDA@MW5PR11MB5881.namprd11.prod.outlook.com>
References: <20230925023813.575016-1-tina.zhang@intel.com>
 <20230925023813.575016-6-tina.zhang@intel.com>
 <20231006180607.GA1140589@nvidia.com>
In-Reply-To: <20231006180607.GA1140589@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?X4oxl8fSwVl3VyJMpcgHDe8MRyrPN3bHj2TkLwR+oGJfWP7f3ZEhxEVAijuU?=
 =?us-ascii?Q?N97AjX0nCwVQTM87edRNCf35H/GN1kEeLw4Sgwbkty3YlaYLDW9PjTgDDhGg?=
 =?us-ascii?Q?vhNgqZ+fqOooM7YWNRUDM1ElOzUfVJQVP0QqJu75ldK3R81wvEg0U8GtmVy9?=
 =?us-ascii?Q?7EFpiNOcaw+qRpkM7HZBugKkGivrSlOmkD/ABxQM5FopM6EX6HBCsyCdHRtJ?=
 =?us-ascii?Q?mjQVA8U78ZA1jQinV0dBj0hFZBEmwhrCcY/lLWlv8cE7MTxjC8tjd19QII8J?=
 =?us-ascii?Q?yP1HQ5O5Se9sNhxCSDyAgn+DL8MnOugtJ/rxtH69GVNzOpmDk38k0bdk9SvF?=
 =?us-ascii?Q?wx7fwkzQEnvNWDqfZgIe64z8gBi1ivCfKvfIIRfG5ol58fU3VS+lWMVOyVCW?=
 =?us-ascii?Q?ZG9OBrjw4C6fa2wDM9fU2R6eAppG8qV7+0IP1AB0DgRxtAsarpJWD7hU1teV?=
 =?us-ascii?Q?b4xNU2ih8qhsGnNWGiTHdx0YxINvRgS8ebXWDzW0idA2HN3lgMIkrXvyURj2?=
 =?us-ascii?Q?VDIuKwxaKM+DMrXtx5cLBm+YssqpbQiNrsAEZCeLxgeMB/tyOY8ze2n68d7v?=
 =?us-ascii?Q?fHUxQOakeR4Nbcb6B4JhVM9ruCgkVK8S6BiwtBlmLxUwjfzKVjfm8Q4zlm/2?=
 =?us-ascii?Q?cJny4ql/GkXlmwPhzXSyMihKF0xyETvBU8RbPcxcnDq8CrjzUQaAA2wJYCzW?=
 =?us-ascii?Q?c04ErnGlDTshRFj+4BhEyUhzi5KA0Hq1AMlGrptT6vzGsIIu8lhMqpvLd1Dp?=
 =?us-ascii?Q?U4nx6ydIbfe3hY+yU0vb28DvFC8y4P03jfFQ25qByY2JozS3PplIAq2Kaz6z?=
 =?us-ascii?Q?zIZrw5QevsjU+8M5q9QkeNidYJ72vIW//PbUUXYkkNC8doOyUXliTz9fvuHV?=
 =?us-ascii?Q?2Iqj9cYEJdRuDmCqYfx3em7P/K1SJcAaZW/kAJ7NaDoevLnG0me+ygu+1feq?=
 =?us-ascii?Q?AE0nqBJ6k4Xn4vRkXJt8l3+wIh/vdvva1Tf1ahaIBSds9Xncp3JbFdi3FyMh?=
 =?us-ascii?Q?GtHvzDoTJM6xmLPi6RRE/AblpNVqpjrvca2nr+6ywV0rlocTtCLUuZDR8mIG?=
 =?us-ascii?Q?4Pa1Oo2bcN568rLpMXNIq9/mfgCzc6GeqFajQp5LaGL05Z8TrevePMg+25+7?=
 =?us-ascii?Q?F2kWzwjgeGBylXXERW3IyemVjkV+Fv7KtIwjz8UbYdX25L7N9lvDbnP9U1KE?=
 =?us-ascii?Q?1ARsXqgDQvTiwpQ7wJ5nH1tpe2x/P94J2aPz/mYJkqtsaZ5tHGpctF+JeuY0?=
 =?us-ascii?Q?PoBdjt6mPazeukCNPC9/ZPg/TOI2oTvq21I3kfb86ASBQcXQa99m0oBJ2mc3?=
 =?us-ascii?Q?0xCS+yj0Xx45+fEfVmOVL2H0XR7i+Rb468vhlMG76hwefqfPbfbI1flxVLJ3?=
 =?us-ascii?Q?TCbEHm7Q9xd62MVjX4gZ32rrvBu4035oZngC0LuQFRZ/RsqHmuWqrnJBTKoe?=
 =?us-ascii?Q?fGtjCmJ6B0zpnRsuex1C8Xje+n1M1uuy37ztVTLO2Q9IdpXdNkrtWWc4VQp7?=
 =?us-ascii?Q?Z/Mq1N6ceKz7mwGn/UphSQL9WrqkR7A/8lZGeeoSUdUM6BmtjAWPVfXjtQlz?=
 =?us-ascii?Q?JvKZJQm+Sz7lbLECxFvR9AHIzQbcAXr0tAWt+vJa?=
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: MW5PR11MB5881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fdbe4448-9c98-4447-79eb-08dbc9962b36
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2023 13:38:20.9767
 (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: a3VrGo2W1t5u7jaKIHqgDLJFtaN0TCeW8+bSkliTWreb4iIMpD+mp9Puk8WdW/Cy+3qn620CArZpXoGckIASFQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5956
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=2.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS,
	URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 10 Oct 2023 06:44:49 -0700 (PDT)
X-Spam-Level: **

Hi Jason,

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Saturday, October 7, 2023 2:06 AM
> To: Zhang, Tina <tina.zhang@intel.com>
> Cc: Tian, Kevin <kevin.tian@intel.com>; Lu Baolu <baolu.lu@linux.intel.co=
m>;
> Michael Shavit <mshavit@google.com>; Vasant Hegde
> <vasant.hegde@amd.com>; iommu@lists.linux.dev; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH v5 5/6] iommu: Support mm PASID 1:n with sva domains
>=20
> On Mon, Sep 25, 2023 at 10:38:12AM +0800, Tina Zhang wrote:
> > Each mm bound to devices gets a PASID and corresponding sva domains
> > allocated in iommu_sva_bind_device(), which are referenced by
> iommu_mm
> > field of the mm. The PASID is released in __mmdrop(), while a sva
> > domain is released when no one is using it (the reference count is
> > decremented in iommu_sva_unbind_device()). However, although sva
> > domains and their PASID are separate objects such that their own life
> > cycles could be handled independently, an enqcmd use case may require
> > releasing the PASID in releasing the mm (i.e., once a PASID is
> > allocated for a mm, it will be permanently used by the mm and won't be
> > released until the end of mm) and only allows to drop the PASID after
> > the sva domains are released. To this end, mmgrab() is called in
> > iommu_sva_domain_alloc() to increment the mm reference count and
> > mmdrop() is invoked in
> > iommu_domain_free() to decrement the mm reference count.
> >
> > Since the required info of PASID and sva domains is kept in struct
> > iommu_mm_data of a mm, use mm->iommu_mm field instead of the old
> pasid
> > field in mm struct. The sva domain list is protected by iommu_sva_lock.
> >
> > Besides, this patch removes mm_pasid_init(), as with the introduced
> > iommu_mm structure, initializing mm pasid in mm_init() is unnecessary.
> >
> > Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> > Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> > Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> > ---
> >
> > Change in v5:
> > - Use smp_store_release() & READ_ONCE() in storing and loading mm's
> >   pasid value.
> >
> > Change in v4:
> > - Rebase to v6.6-rc1.
> >
> >  drivers/iommu/iommu-sva.c | 40 +++++++++++++++++++++++++++-----------
> -
> >  include/linux/iommu.h     | 18 +++++++++++-------
> >  kernel/fork.c             |  1 -
> >  3 files changed, 39 insertions(+), 20 deletions(-)
>=20
> I was wondering what Nicolin's issue was, didn't see anything.
>=20
> But I think you should incorporate this into the patch.
>=20
> And there is a straightforward way to move the global lock into the
> iommu_mm_data that we can explore later.
OK. Let's try it. Hope this could solve the issue reported by Nicolin.

Regards,
-Tina