[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNUSEiXTYbV7ML6x@ziepe.ca>
Date: Thu, 10 Aug 2023 13:36:34 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: "Tian, Kevin" <kevin.tian@...el.com>
Cc: Baolu Lu <baolu.lu@...ux.intel.com>,
"Zhang, Tina" <tina.zhang@...el.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 2/5] iommu: Call helper function to get assigned pasid
value
On Thu, Aug 10, 2023 at 07:52:52AM +0000, Tian, Kevin wrote:
> > The driver should rely on there being exactly one iommu_domain for SVA
> > per mm so it can hang the mm_notifier off the iommu_domain
>
> I'm confused. Isn't this series trying to allow multiple domains per mm?
It is doing both.
The main objective is to allow de-duplicating the SVA domains in the
core code. The driver should be able to assume one SVA domain per
instance, or even one SVA domain per compatible instance. The driver
should not do any de-duplication.
But we can't just store a single iommu_domain in the mm_struct - we
have the same problem as iommufd and we need to create more domains if
the domains we already have are incompatible with the device.
Arguably this should not happen, and in any sane configuration we
should have only 1 type of IOMMU driver that needs only 1 SVA domain.
But right now things like SMMUv3 have problems crossing domains across
instances, so we could have one SVA domain per IOMMU instance until
that is fixed.
Jason
Powered by blists - more mailing lists