[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB527654AF38084B07EC7734468C12A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Wed, 9 Aug 2023 09:47:15 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jason Gunthorpe <jgg@...pe.ca>,
"Zhang, Tina" <tina.zhang@...el.com>
CC: Lu Baolu <baolu.lu@...ux.intel.com>,
Michael Shavit <mshavit@...gle.com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/5] iommu: Add mm_get_pasid() helper function
> From: Jason Gunthorpe <jgg@...pe.ca>
> Sent: Tuesday, August 8, 2023 11:02 PM
>
> On Tue, Aug 08, 2023 at 03:49:40PM +0800, Tina Zhang wrote:
> > mm_get_pasid() is for getting mm pasid value.
> >
> > The motivation is to replace mm->pasid with an iommu private data
> > structure that is introduced in a later patch.
>
> Maybe we should start out by calling it what it actually is:
>
> 'mm_get_enqcmd_pasid()'
>
> We can't actually have multiple SVA domains with different PASIDs
> until the places wrongly calling this are removed :\
>
it's kind of egg-chicken problem. mm_get_pasid() is used by all SVA
scenarios beyond enqcmd then calling it mm_get_enqcmd_pasid()
also sounds weird for non-enqcmd case.
unless you were suggesting to just create a new wrapper for this
specific enqcmd path (try_fixup_enqcmd_gp()) then I'm fine. 😊
Powered by blists - more mailing lists