* [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
2023-10-27 0:05 [PATCH v10 0/6] Share sva domains with all devices bound to a mm Tina Zhang
@ 2023-10-27 0:05 ` Tina Zhang
2023-10-27 7:12 ` Joerg Roedel
2023-10-27 0:05 ` [PATCH v10 2/6] iommu/vt-d: Remove mm->pasid in intel_sva_bind_mm() Tina Zhang
` (5 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Tina Zhang @ 2023-10-27 0:05 UTC (permalink / raw)
To: iommu, linux-kernel
Cc: David Woodhouse, Lu Baolu, Joerg Roedel, Will Deacon,
Robin Murphy, Jason Gunthorpe, Kevin Tian, Nicolin Chen,
Michael Shavit, Vasant Hegde, Jason Gunthorpe
From: Jason Gunthorpe <jgg@nvidia.com>
Linus suggested that the kconfig here is confusing:
https://lore.kernel.org/all/CAHk-=wgUiAtiszwseM1p2fCJ+sC4XWQ+YN4TanFhUgvUqjr9Xw@mail.gmail.com/
Let's break it into three kconfigs controlling distinct things:
- CONFIG_IOMMU_MM_DATA controls if the mm_struct has the additional
fields for the IOMMU. Currently only PASID, but later patches store
a struct iommu_mm_data *
- CONFIG_ARCH_HAS_CPU_PASID controls if the arch needs the scheduling bit
for keeping track of the ENQCMD instruction. x86 will select this if
IOMMU_SVA is enabled
- IOMMU_SVA controls if the IOMMU core compiles in the SVA support code
for iommu driver use and the IOMMU exported API
This way ARM will not enable CONFIG_ARCH_HAS_CPU_PASID
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
arch/Kconfig | 5 +++++
arch/x86/Kconfig | 1 +
arch/x86/kernel/traps.c | 2 +-
drivers/iommu/Kconfig | 1 +
include/linux/iommu.h | 2 +-
include/linux/mm_types.h | 2 +-
include/linux/sched.h | 2 +-
kernel/fork.c | 2 +-
mm/Kconfig | 3 +++
mm/init-mm.c | 2 +-
10 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 12d51495caec..35b9fd559bb6 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -301,6 +301,11 @@ config ARCH_HAS_DMA_CLEAR_UNCACHED
config ARCH_HAS_CPU_FINALIZE_INIT
bool
+# The architecture has a per-task state that includes the mm's PASID
+config ARCH_HAS_CPU_PASID
+ bool
+ select IOMMU_MM_DATA
+
# Select if arch init_task must go in the __init_task_data section
config ARCH_TASK_STRUCT_ON_STACK
bool
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 66bfabae8814..afd9c2dc228b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -72,6 +72,7 @@ config X86
select ARCH_HAS_CACHE_LINE_SIZE
select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
select ARCH_HAS_CPU_FINALIZE_INIT
+ select ARCH_HAS_CPU_PASID if IOMMU_SVA
select ARCH_HAS_CURRENT_STACK_POINTER
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEBUG_VM_PGTABLE if !X86_PAE
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index c876f1d36a81..2b62dbb3396a 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -565,7 +565,7 @@ static bool fixup_iopl_exception(struct pt_regs *regs)
*/
static bool try_fixup_enqcmd_gp(void)
{
-#ifdef CONFIG_IOMMU_SVA
+#ifdef CONFIG_ARCH_HAS_CPU_PASID
u32 pasid;
/*
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 3199fd54b462..52fa02f1b675 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -156,6 +156,7 @@ config IOMMU_DMA
# Shared Virtual Addressing
config IOMMU_SVA
+ select IOMMU_MM_DATA
bool
config FSL_PAMU
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b5b254e205c6..c1f2b6f9a3d0 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -1189,7 +1189,7 @@ static inline bool tegra_dev_iommu_get_stream_id(struct device *dev, u32 *stream
return false;
}
-#ifdef CONFIG_IOMMU_SVA
+#ifdef CONFIG_IOMMU_MM_DATA
static inline void mm_pasid_init(struct mm_struct *mm)
{
mm->pasid = IOMMU_PASID_INVALID;
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 36c5b43999e6..330f3cd8d5ad 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -881,7 +881,7 @@ struct mm_struct {
#endif
struct work_struct async_put_work;
-#ifdef CONFIG_IOMMU_SVA
+#ifdef CONFIG_IOMMU_MM_DATA
u32 pasid;
#endif
#ifdef CONFIG_KSM
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 77f01ac385f7..3ac8e8556c3d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -949,7 +949,7 @@ struct task_struct {
/* Recursion prevention for eventfd_signal() */
unsigned in_eventfd:1;
#endif
-#ifdef CONFIG_IOMMU_SVA
+#ifdef CONFIG_ARCH_HAS_CPU_PASID
unsigned pasid_activated:1;
#endif
#ifdef CONFIG_CPU_SUP_INTEL
diff --git a/kernel/fork.c b/kernel/fork.c
index 3b6d20dfb9a8..d28f0d4582dc 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1179,7 +1179,7 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
tsk->use_memdelay = 0;
#endif
-#ifdef CONFIG_IOMMU_SVA
+#ifdef CONFIG_ARCH_HAS_CPU_PASID
tsk->pasid_activated = 0;
#endif
diff --git a/mm/Kconfig b/mm/Kconfig
index 264a2df5ecf5..fee4a15e444b 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -1258,6 +1258,9 @@ config LOCK_MM_AND_FIND_VMA
bool
depends on !STACK_GROWSUP
+config IOMMU_MM_DATA
+ bool
+
source "mm/damon/Kconfig"
endmenu
diff --git a/mm/init-mm.c b/mm/init-mm.c
index cfd367822cdd..c52dc2740a3d 100644
--- a/mm/init-mm.c
+++ b/mm/init-mm.c
@@ -44,7 +44,7 @@ struct mm_struct init_mm = {
#endif
.user_ns = &init_user_ns,
.cpu_bitmap = CPU_BITS_NONE,
-#ifdef CONFIG_IOMMU_SVA
+#ifdef CONFIG_IOMMU_MM_DATA
.pasid = IOMMU_PASID_INVALID,
#endif
INIT_MM_CONTEXT(init_mm)
--
2.39.3
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
2023-10-27 0:05 ` [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA Tina Zhang
@ 2023-10-27 7:12 ` Joerg Roedel
2023-10-27 7:36 ` Zhang, Tina
0 siblings, 1 reply; 24+ messages in thread
From: Joerg Roedel @ 2023-10-27 7:12 UTC (permalink / raw)
To: Tina Zhang
Cc: iommu, linux-kernel, David Woodhouse, Lu Baolu, Will Deacon,
Robin Murphy, Jason Gunthorpe, Kevin Tian, Nicolin Chen,
Michael Shavit, Vasant Hegde, Jason Gunthorpe
Hi Tina,
On Fri, Oct 27, 2023 at 08:05:20AM +0800, Tina Zhang wrote:
> From: Jason Gunthorpe <jgg@nvidia.com>
>
> Linus suggested that the kconfig here is confusing:
While this patch looks decent to me, you forgot to Cc Linus on it. In
general, given that it touches a couple of core files, I'd like to wait
for some more people to have a look at it and not rushing anything in.
>
> https://lore.kernel.org/all/CAHk-=wgUiAtiszwseM1p2fCJ+sC4XWQ+YN4TanFhUgvUqjr9Xw@mail.gmail.com/
>
> Let's break it into three kconfigs controlling distinct things:
>
> - CONFIG_IOMMU_MM_DATA controls if the mm_struct has the additional
> fields for the IOMMU. Currently only PASID, but later patches store
> a struct iommu_mm_data *
>
> - CONFIG_ARCH_HAS_CPU_PASID controls if the arch needs the scheduling bit
> for keeping track of the ENQCMD instruction. x86 will select this if
> IOMMU_SVA is enabled
>
> - IOMMU_SVA controls if the IOMMU core compiles in the SVA support code
> for iommu driver use and the IOMMU exported API
>
> This way ARM will not enable CONFIG_ARCH_HAS_CPU_PASID
>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
If you send it, you also need to add your Signed-off-by.
Regards,
Joerg
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
2023-10-27 7:12 ` Joerg Roedel
@ 2023-10-27 7:36 ` Zhang, Tina
2023-10-27 9:14 ` Zhang, Tina
0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Tina @ 2023-10-27 7:36 UTC (permalink / raw)
To: Joerg Roedel
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Lu Baolu, Will Deacon, Robin Murphy,
Jason Gunthorpe, Tian, Kevin, Nicolin Chen, Michael Shavit,
Vasant Hegde, Jason Gunthorpe
Hi Joerg,
> -----Original Message-----
> From: Joerg Roedel <joro@8bytes.org>
> Sent: Friday, October 27, 2023 3:12 PM
> To: Zhang, Tina <tina.zhang@intel.com>
> Cc: iommu@lists.linux.dev; linux-kernel@vger.kernel.org; David Woodhouse
> <dwmw2@infradead.org>; Lu Baolu <baolu.lu@linux.intel.com>; Will Deacon
> <will@kernel.org>; Robin Murphy <robin.murphy@arm.com>; Jason
> Gunthorpe <jgg@ziepe.ca>; Tian, Kevin <kevin.tian@intel.com>; Nicolin Chen
> <nicolinc@nvidia.com>; Michael Shavit <mshavit@google.com>; Vasant
> Hegde <vasant.hegde@amd.com>; Jason Gunthorpe <jgg@nvidia.com>
> Subject: Re: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
>
> Hi Tina,
>
> On Fri, Oct 27, 2023 at 08:05:20AM +0800, Tina Zhang wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> >
> > Linus suggested that the kconfig here is confusing:
>
> While this patch looks decent to me, you forgot to Cc Linus on it. In general,
> given that it touches a couple of core files, I'd like to wait for some more
> people to have a look at it and not rushing anything in.
Make sense. I'll CC Linus. Comments are welcome.
> >
> > https://lore.kernel.org/all/CAHk-
> =wgUiAtiszwseM1p2fCJ+sC4XWQ+YN4TanFhU
> > gvUqjr9Xw@mail.gmail.com/
> >
> > Let's break it into three kconfigs controlling distinct things:
> >
> > - CONFIG_IOMMU_MM_DATA controls if the mm_struct has the additional
> > fields for the IOMMU. Currently only PASID, but later patches store
> > a struct iommu_mm_data *
> >
> > - CONFIG_ARCH_HAS_CPU_PASID controls if the arch needs the scheduling
> bit
> > for keeping track of the ENQCMD instruction. x86 will select this if
> > IOMMU_SVA is enabled
> >
> > - IOMMU_SVA controls if the IOMMU core compiles in the SVA support
> code
> > for iommu driver use and the IOMMU exported API
> >
> > This way ARM will not enable CONFIG_ARCH_HAS_CPU_PASID
> >
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
>
> If you send it, you also need to add your Signed-off-by.
OK. I'll add my Signed-off-by.
Thanks,
-Tina
>
> Regards,
>
> Joerg
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
2023-10-27 7:36 ` Zhang, Tina
@ 2023-10-27 9:14 ` Zhang, Tina
2023-10-27 11:20 ` Jason Gunthorpe
0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Tina @ 2023-10-27 9:14 UTC (permalink / raw)
To: Joerg Roedel
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Lu Baolu, Will Deacon, Robin Murphy,
Jason Gunthorpe, Tian, Kevin, Nicolin Chen, Michael Shavit,
Vasant Hegde, Jason Gunthorpe
Hi Joerg and Jason,
> -----Original Message-----
> From: Zhang, Tina
> Sent: Friday, October 27, 2023 3:37 PM
> To: Joerg Roedel <joro@8bytes.org>
> Cc: iommu@lists.linux.dev; linux-kernel@vger.kernel.org; David Woodhouse
> <dwmw2@infradead.org>; Lu Baolu <baolu.lu@linux.intel.com>; Will Deacon
> <will@kernel.org>; Robin Murphy <robin.murphy@arm.com>; Jason
> Gunthorpe <jgg@ziepe.ca>; Tian, Kevin <kevin.tian@intel.com>; Nicolin Chen
> <nicolinc@nvidia.com>; Michael Shavit <mshavit@google.com>; Vasant
> Hegde <vasant.hegde@amd.com>; Jason Gunthorpe <jgg@nvidia.com>
> Subject: RE: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
>
> Hi Joerg,
>
> > -----Original Message-----
> > From: Joerg Roedel <joro@8bytes.org>
> > Sent: Friday, October 27, 2023 3:12 PM
> > To: Zhang, Tina <tina.zhang@intel.com>
> > Cc: iommu@lists.linux.dev; linux-kernel@vger.kernel.org; David
> > Woodhouse <dwmw2@infradead.org>; Lu Baolu
> <baolu.lu@linux.intel.com>;
> > Will Deacon <will@kernel.org>; Robin Murphy <robin.murphy@arm.com>;
> > Jason Gunthorpe <jgg@ziepe.ca>; Tian, Kevin <kevin.tian@intel.com>;
> > Nicolin Chen <nicolinc@nvidia.com>; Michael Shavit
> > <mshavit@google.com>; Vasant Hegde <vasant.hegde@amd.com>; Jason
> > Gunthorpe <jgg@nvidia.com>
> > Subject: Re: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
> >
> > Hi Tina,
> >
> > On Fri, Oct 27, 2023 at 08:05:20AM +0800, Tina Zhang wrote:
> > > From: Jason Gunthorpe <jgg@nvidia.com>
> > >
> > > Linus suggested that the kconfig here is confusing:
> >
> > While this patch looks decent to me, you forgot to Cc Linus on it. In
> > general, given that it touches a couple of core files, I'd like to
> > wait for some more people to have a look at it and not rushing anything in.
> Make sense. I'll CC Linus. Comments are welcome.
Can we separate this patch? I'm thinking about CC more people for review. At least, we need to CC all the reviewers of https://lore.kernel.org/all/20230506133134.1492395-1-jacob.jun.pan@linux.intel.com/ to this patch. So, it seems more reasonable to separate this patch. What do you think?
Regards,
-Tina
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
2023-10-27 9:14 ` Zhang, Tina
@ 2023-10-27 11:20 ` Jason Gunthorpe
2023-11-27 18:24 ` Jason Gunthorpe
0 siblings, 1 reply; 24+ messages in thread
From: Jason Gunthorpe @ 2023-10-27 11:20 UTC (permalink / raw)
To: Zhang, Tina
Cc: Joerg Roedel, iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Lu Baolu, Will Deacon, Robin Murphy, Tian, Kevin,
Nicolin Chen, Michael Shavit, Vasant Hegde
On Fri, Oct 27, 2023 at 09:14:17AM +0000, Zhang, Tina wrote:
> > > On Fri, Oct 27, 2023 at 08:05:20AM +0800, Tina Zhang wrote:
> > > > From: Jason Gunthorpe <jgg@nvidia.com>
> > > >
> > > > Linus suggested that the kconfig here is confusing:
> > >
> > > While this patch looks decent to me, you forgot to Cc Linus on it. In
> > > general, given that it touches a couple of core files, I'd like to
> > > wait for some more people to have a look at it and not rushing anything in.
> > Make sense. I'll CC Linus. Comments are welcome.
> Can we separate this patch? I'm thinking about CC more people for
> review. At least, we need to CC all the reviewers of
> https://lore.kernel.org/all/20230506133134.1492395-1-jacob.jun.pan@linux.intel.com/
> to this patch. So, it seems more reasonable to separate this
> patch. What do you think?
I think that makes sense, let's go ahead with the rest of the SVA
series and we can do this next cycle. Bikeshedding config names isn't
really critical.
Jason
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
2023-10-27 11:20 ` Jason Gunthorpe
@ 2023-11-27 18:24 ` Jason Gunthorpe
2023-11-28 0:23 ` Zhang, Tina
0 siblings, 1 reply; 24+ messages in thread
From: Jason Gunthorpe @ 2023-11-27 18:24 UTC (permalink / raw)
To: Zhang, Tina
Cc: Joerg Roedel, iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Lu Baolu, Will Deacon, Robin Murphy, Tian, Kevin,
Nicolin Chen, Michael Shavit, Vasant Hegde
On Fri, Oct 27, 2023 at 08:20:13AM -0300, Jason Gunthorpe wrote:
> On Fri, Oct 27, 2023 at 09:14:17AM +0000, Zhang, Tina wrote:
> > > > On Fri, Oct 27, 2023 at 08:05:20AM +0800, Tina Zhang wrote:
> > > > > From: Jason Gunthorpe <jgg@nvidia.com>
> > > > >
> > > > > Linus suggested that the kconfig here is confusing:
> > > >
> > > > While this patch looks decent to me, you forgot to Cc Linus on it. In
> > > > general, given that it touches a couple of core files, I'd like to
> > > > wait for some more people to have a look at it and not rushing anything in.
> > > Make sense. I'll CC Linus. Comments are welcome.
>
> > Can we separate this patch? I'm thinking about CC more people for
> > review. At least, we need to CC all the reviewers of
> > https://lore.kernel.org/all/20230506133134.1492395-1-jacob.jun.pan@linux.intel.com/
> > to this patch. So, it seems more reasonable to separate this
> > patch. What do you think?
>
> I think that makes sense, let's go ahead with the rest of the SVA
> series and we can do this next cycle. Bikeshedding config names isn't
> really critical.
So this didn't make it even without the config change :(
Can you please resend it again and CC the right please please. This
needs to go into this cycle for sure
Thanks
Jason
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
2023-11-27 18:24 ` Jason Gunthorpe
@ 2023-11-28 0:23 ` Zhang, Tina
0 siblings, 0 replies; 24+ messages in thread
From: Zhang, Tina @ 2023-11-28 0:23 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Joerg Roedel, iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Lu Baolu, Will Deacon, Robin Murphy, Tian, Kevin,
Nicolin Chen, Michael Shavit, Vasant Hegde
> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Tuesday, November 28, 2023 2:25 AM
> To: Zhang, Tina <tina.zhang@intel.com>
> Cc: Joerg Roedel <joro@8bytes.org>; iommu@lists.linux.dev; linux-
> kernel@vger.kernel.org; David Woodhouse <dwmw2@infradead.org>; Lu
> Baolu <baolu.lu@linux.intel.com>; Will Deacon <will@kernel.org>; Robin
> Murphy <robin.murphy@arm.com>; Tian, Kevin <kevin.tian@intel.com>;
> Nicolin Chen <nicolinc@nvidia.com>; Michael Shavit <mshavit@google.com>;
> Vasant Hegde <vasant.hegde@amd.com>
> Subject: Re: [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA
>
> On Fri, Oct 27, 2023 at 08:20:13AM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 27, 2023 at 09:14:17AM +0000, Zhang, Tina wrote:
> > > > > On Fri, Oct 27, 2023 at 08:05:20AM +0800, Tina Zhang wrote:
> > > > > > From: Jason Gunthorpe <jgg@nvidia.com>
> > > > > >
> > > > > > Linus suggested that the kconfig here is confusing:
> > > > >
> > > > > While this patch looks decent to me, you forgot to Cc Linus on
> > > > > it. In general, given that it touches a couple of core files,
> > > > > I'd like to wait for some more people to have a look at it and not rushing
> anything in.
> > > > Make sense. I'll CC Linus. Comments are welcome.
> >
> > > Can we separate this patch? I'm thinking about CC more people for
> > > review. At least, we need to CC all the reviewers of
> > > https://lore.kernel.org/all/20230506133134.1492395-1-
> jacob.jun.pan@l
> > > inux.intel.com/ to this patch. So, it seems more reasonable to
> > > separate this patch. What do you think?
> >
> > I think that makes sense, let's go ahead with the rest of the SVA
> > series and we can do this next cycle. Bikeshedding config names isn't
> > really critical.
>
> So this didn't make it even without the config change :(
>
> Can you please resend it again and CC the right please please. This needs to go
> into this cycle for sure
Sure.
Regards,
-Tina
>
> Thanks
> Jason
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v10 2/6] iommu/vt-d: Remove mm->pasid in intel_sva_bind_mm()
2023-10-27 0:05 [PATCH v10 0/6] Share sva domains with all devices bound to a mm Tina Zhang
2023-10-27 0:05 ` [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA Tina Zhang
@ 2023-10-27 0:05 ` Tina Zhang
2023-10-27 0:05 ` [PATCH v10 3/6] iommu: Add mm_get_enqcmd_pasid() helper function Tina Zhang
` (4 subsequent siblings)
6 siblings, 0 replies; 24+ messages in thread
From: Tina Zhang @ 2023-10-27 0:05 UTC (permalink / raw)
To: iommu, linux-kernel
Cc: David Woodhouse, Lu Baolu, Joerg Roedel, Will Deacon,
Robin Murphy, Jason Gunthorpe, Kevin Tian, Nicolin Chen,
Michael Shavit, Vasant Hegde, Tina Zhang, Jason Gunthorpe
The pasid is passed in as a parameter through .set_dev_pasid() callback.
Thus, intel_sva_bind_mm() can directly use it instead of retrieving the
pasid value from mm->pasid.
Suggested-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/iommu/intel/svm.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 50a481c895b8..3c531af58658 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -290,21 +290,22 @@ static int pasid_to_svm_sdev(struct device *dev, unsigned int pasid,
}
static int intel_svm_bind_mm(struct intel_iommu *iommu, struct device *dev,
- struct mm_struct *mm)
+ struct iommu_domain *domain, ioasid_t pasid)
{
struct device_domain_info *info = dev_iommu_priv_get(dev);
+ struct mm_struct *mm = domain->mm;
struct intel_svm_dev *sdev;
struct intel_svm *svm;
unsigned long sflags;
int ret = 0;
- svm = pasid_private_find(mm->pasid);
+ svm = pasid_private_find(pasid);
if (!svm) {
svm = kzalloc(sizeof(*svm), GFP_KERNEL);
if (!svm)
return -ENOMEM;
- svm->pasid = mm->pasid;
+ svm->pasid = pasid;
svm->mm = mm;
INIT_LIST_HEAD_RCU(&svm->devs);
@@ -342,7 +343,7 @@ static int intel_svm_bind_mm(struct intel_iommu *iommu, struct device *dev,
/* Setup the pasid table: */
sflags = cpu_feature_enabled(X86_FEATURE_LA57) ? PASID_FLAG_FL5LP : 0;
- ret = intel_pasid_setup_first_level(iommu, dev, mm->pgd, mm->pasid,
+ ret = intel_pasid_setup_first_level(iommu, dev, mm->pgd, pasid,
FLPT_DEFAULT_DID, sflags);
if (ret)
goto free_sdev;
@@ -356,7 +357,7 @@ static int intel_svm_bind_mm(struct intel_iommu *iommu, struct device *dev,
free_svm:
if (list_empty(&svm->devs)) {
mmu_notifier_unregister(&svm->notifier, mm);
- pasid_private_remove(mm->pasid);
+ pasid_private_remove(pasid);
kfree(svm);
}
@@ -796,9 +797,8 @@ static int intel_svm_set_dev_pasid(struct iommu_domain *domain,
{
struct device_domain_info *info = dev_iommu_priv_get(dev);
struct intel_iommu *iommu = info->iommu;
- struct mm_struct *mm = domain->mm;
- return intel_svm_bind_mm(iommu, dev, mm);
+ return intel_svm_bind_mm(iommu, dev, domain, pasid);
}
static void intel_svm_domain_free(struct iommu_domain *domain)
--
2.39.3
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v10 3/6] iommu: Add mm_get_enqcmd_pasid() helper function
2023-10-27 0:05 [PATCH v10 0/6] Share sva domains with all devices bound to a mm Tina Zhang
2023-10-27 0:05 ` [PATCH v10 1/6] iommu: Change kconfig around IOMMU_SVA Tina Zhang
2023-10-27 0:05 ` [PATCH v10 2/6] iommu/vt-d: Remove mm->pasid in intel_sva_bind_mm() Tina Zhang
@ 2023-10-27 0:05 ` Tina Zhang
2023-10-27 0:05 ` [PATCH v10 4/6] mm: Add structure to keep sva information Tina Zhang
` (3 subsequent siblings)
6 siblings, 0 replies; 24+ messages in thread
From: Tina Zhang @ 2023-10-27 0:05 UTC (permalink / raw)
To: iommu, linux-kernel
Cc: David Woodhouse, Lu Baolu, Joerg Roedel, Will Deacon,
Robin Murphy, Jason Gunthorpe, Kevin Tian, Nicolin Chen,
Michael Shavit, Vasant Hegde, Tina Zhang, Jason Gunthorpe
mm_get_enqcmd_pasid() should be used by architecture code and closely
related to learn the PASID value that the x86 ENQCMD operation should
use for the mm.
For the moment SMMUv3 uses this without any connection to ENQCMD, it
will be cleaned up similar to how the prior patch made VT-d use the
PASID argument of set_dev_pasid().
The motivation is to replace mm->pasid with an iommu private data
structure that is introduced in a later patch.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
arch/x86/kernel/traps.c | 2 +-
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 23 ++++++++++++-------
drivers/iommu/iommu-sva.c | 2 +-
include/linux/iommu.h | 12 ++++++++++
4 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 2b62dbb3396a..5944d759afe7 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -591,7 +591,7 @@ static bool try_fixup_enqcmd_gp(void)
if (!mm_valid_pasid(current->mm))
return false;
- pasid = current->mm->pasid;
+ pasid = mm_get_enqcmd_pasid(current->mm);
/*
* Did this thread already have its PASID activated?
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 353248ab18e7..05722121f00e 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -246,7 +246,8 @@ static void arm_smmu_mm_arch_invalidate_secondary_tlbs(struct mmu_notifier *mn,
smmu_domain);
}
- arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, start, size);
+ arm_smmu_atc_inv_domain(smmu_domain, mm_get_enqcmd_pasid(mm), start,
+ size);
}
static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
@@ -264,10 +265,11 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
* DMA may still be running. Keep the cd valid to avoid C_BAD_CD events,
* but disable translation.
*/
- arm_smmu_update_ctx_desc_devices(smmu_domain, mm->pasid, &quiet_cd);
+ arm_smmu_update_ctx_desc_devices(smmu_domain, mm_get_enqcmd_pasid(mm),
+ &quiet_cd);
arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_mn->cd->asid);
- arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, 0, 0);
+ arm_smmu_atc_inv_domain(smmu_domain, mm_get_enqcmd_pasid(mm), 0, 0);
smmu_mn->cleared = true;
mutex_unlock(&sva_lock);
@@ -325,10 +327,13 @@ arm_smmu_mmu_notifier_get(struct arm_smmu_domain *smmu_domain,
spin_lock_irqsave(&smmu_domain->devices_lock, flags);
list_for_each_entry(master, &smmu_domain->devices, domain_head) {
- ret = arm_smmu_write_ctx_desc(master, mm->pasid, cd);
+ ret = arm_smmu_write_ctx_desc(master, mm_get_enqcmd_pasid(mm),
+ cd);
if (ret) {
- list_for_each_entry_from_reverse(master, &smmu_domain->devices, domain_head)
- arm_smmu_write_ctx_desc(master, mm->pasid, NULL);
+ list_for_each_entry_from_reverse(
+ master, &smmu_domain->devices, domain_head)
+ arm_smmu_write_ctx_desc(
+ master, mm_get_enqcmd_pasid(mm), NULL);
break;
}
}
@@ -358,7 +363,8 @@ static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
list_del(&smmu_mn->list);
- arm_smmu_update_ctx_desc_devices(smmu_domain, mm->pasid, NULL);
+ arm_smmu_update_ctx_desc_devices(smmu_domain, mm_get_enqcmd_pasid(mm),
+ NULL);
/*
* If we went through clear(), we've already invalidated, and no
@@ -366,7 +372,8 @@ static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
*/
if (!smmu_mn->cleared) {
arm_smmu_tlb_inv_asid(smmu_domain->smmu, cd->asid);
- arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, 0, 0);
+ arm_smmu_atc_inv_domain(smmu_domain, mm_get_enqcmd_pasid(mm), 0,
+ 0);
}
/* Frees smmu_mn */
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index b78671a8a914..4a2f5699747f 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -141,7 +141,7 @@ u32 iommu_sva_get_pasid(struct iommu_sva *handle)
{
struct iommu_domain *domain = handle->domain;
- return domain->mm->pasid;
+ return mm_get_enqcmd_pasid(domain->mm);
}
EXPORT_SYMBOL_GPL(iommu_sva_get_pasid);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index c1f2b6f9a3d0..95792bf42f96 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -1198,6 +1198,12 @@ static inline bool mm_valid_pasid(struct mm_struct *mm)
{
return mm->pasid != IOMMU_PASID_INVALID;
}
+
+static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
+{
+ return mm->pasid;
+}
+
void mm_pasid_drop(struct mm_struct *mm);
struct iommu_sva *iommu_sva_bind_device(struct device *dev,
struct mm_struct *mm);
@@ -1220,6 +1226,12 @@ static inline u32 iommu_sva_get_pasid(struct iommu_sva *handle)
}
static inline void mm_pasid_init(struct mm_struct *mm) {}
static inline bool mm_valid_pasid(struct mm_struct *mm) { return false; }
+
+static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
+{
+ return IOMMU_PASID_INVALID;
+}
+
static inline void mm_pasid_drop(struct mm_struct *mm) {}
#endif /* CONFIG_IOMMU_SVA */
--
2.39.3
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v10 4/6] mm: Add structure to keep sva information
2023-10-27 0:05 [PATCH v10 0/6] Share sva domains with all devices bound to a mm Tina Zhang
` (2 preceding siblings ...)
2023-10-27 0:05 ` [PATCH v10 3/6] iommu: Add mm_get_enqcmd_pasid() helper function Tina Zhang
@ 2023-10-27 0:05 ` Tina Zhang
2023-10-27 0:05 ` [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains Tina Zhang
` (2 subsequent siblings)
6 siblings, 0 replies; 24+ messages in thread
From: Tina Zhang @ 2023-10-27 0:05 UTC (permalink / raw)
To: iommu, linux-kernel
Cc: David Woodhouse, Lu Baolu, Joerg Roedel, Will Deacon,
Robin Murphy, Jason Gunthorpe, Kevin Tian, Nicolin Chen,
Michael Shavit, Vasant Hegde, Tina Zhang, Jason Gunthorpe
Introduce iommu_mm_data structure to keep sva information (pasid and the
related sva domains). Add iommu_mm pointer, pointing to an instance of
iommu_mm_data structure, to mm.
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
include/linux/iommu.h | 5 +++++
include/linux/mm_types.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 95792bf42f96..a807182c3d2e 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -679,6 +679,11 @@ struct iommu_sva {
struct iommu_domain *domain;
};
+struct iommu_mm_data {
+ u32 pasid;
+ struct list_head sva_domains;
+};
+
int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
const struct iommu_ops *ops);
void iommu_fwspec_free(struct device *dev);
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 330f3cd8d5ad..2dbf18e26c5a 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -670,6 +670,7 @@ struct mm_cid {
#endif
struct kioctx_table;
+struct iommu_mm_data;
struct mm_struct {
struct {
/*
@@ -883,6 +884,7 @@ struct mm_struct {
#ifdef CONFIG_IOMMU_MM_DATA
u32 pasid;
+ struct iommu_mm_data *iommu_mm;
#endif
#ifdef CONFIG_KSM
/*
--
2.39.3
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2023-10-27 0:05 [PATCH v10 0/6] Share sva domains with all devices bound to a mm Tina Zhang
` (3 preceding siblings ...)
2023-10-27 0:05 ` [PATCH v10 4/6] mm: Add structure to keep sva information Tina Zhang
@ 2023-10-27 0:05 ` Tina Zhang
2024-02-20 16:26 ` Zhangfei Gao
2023-10-27 0:05 ` [PATCH v10 6/6] mm: Deprecate pasid field Tina Zhang
2023-12-12 9:12 ` [PATCH v10 0/6] Share sva domains with all devices bound to a mm Joerg Roedel
6 siblings, 1 reply; 24+ messages in thread
From: Tina Zhang @ 2023-10-27 0:05 UTC (permalink / raw)
To: iommu, linux-kernel
Cc: David Woodhouse, Lu Baolu, Joerg Roedel, Will Deacon,
Robin Murphy, Jason Gunthorpe, Kevin Tian, Nicolin Chen,
Michael Shavit, Vasant Hegde, Tina Zhang, Jason Gunthorpe
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>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/iommu/iommu-sva.c | 92 +++++++++++++++++++++++----------------
include/linux/iommu.h | 23 ++++++++--
2 files changed, 74 insertions(+), 41 deletions(-)
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index 4a2f5699747f..5175e8d85247 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -12,32 +12,42 @@
static DEFINE_MUTEX(iommu_sva_lock);
/* Allocate a PASID for the mm within range (inclusive) */
-static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
+static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct device *dev)
{
+ struct iommu_mm_data *iommu_mm;
ioasid_t pasid;
- int ret = 0;
+
+ lockdep_assert_held(&iommu_sva_lock);
if (!arch_pgtable_dma_compat(mm))
- return -EBUSY;
+ return ERR_PTR(-EBUSY);
- mutex_lock(&iommu_sva_lock);
+ iommu_mm = mm->iommu_mm;
/* Is a PASID already associated with this mm? */
- if (mm_valid_pasid(mm)) {
- if (mm->pasid >= dev->iommu->max_pasids)
- ret = -EOVERFLOW;
- goto out;
+ if (iommu_mm) {
+ if (iommu_mm->pasid >= dev->iommu->max_pasids)
+ return ERR_PTR(-EOVERFLOW);
+ return iommu_mm;
}
+ iommu_mm = kzalloc(sizeof(struct iommu_mm_data), GFP_KERNEL);
+ if (!iommu_mm)
+ return ERR_PTR(-ENOMEM);
+
pasid = iommu_alloc_global_pasid(dev);
if (pasid == IOMMU_PASID_INVALID) {
- ret = -ENOSPC;
- goto out;
+ kfree(iommu_mm);
+ return ERR_PTR(-ENOSPC);
}
- mm->pasid = pasid;
- ret = 0;
-out:
- mutex_unlock(&iommu_sva_lock);
- return ret;
+ iommu_mm->pasid = pasid;
+ INIT_LIST_HEAD(&iommu_mm->sva_domains);
+ /*
+ * Make sure the write to mm->iommu_mm is not reordered in front of
+ * initialization to iommu_mm fields. If it does, readers may see a
+ * valid iommu_mm with uninitialized values.
+ */
+ smp_store_release(&mm->iommu_mm, iommu_mm);
+ return iommu_mm;
}
/**
@@ -58,31 +68,33 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
*/
struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
{
+ struct iommu_mm_data *iommu_mm;
struct iommu_domain *domain;
struct iommu_sva *handle;
int ret;
+ mutex_lock(&iommu_sva_lock);
+
/* Allocate mm->pasid if necessary. */
- ret = iommu_sva_alloc_pasid(mm, dev);
- if (ret)
- return ERR_PTR(ret);
+ iommu_mm = iommu_alloc_mm_data(mm, dev);
+ if (IS_ERR(iommu_mm)) {
+ ret = PTR_ERR(iommu_mm);
+ goto out_unlock;
+ }
handle = kzalloc(sizeof(*handle), GFP_KERNEL);
- if (!handle)
- return ERR_PTR(-ENOMEM);
-
- mutex_lock(&iommu_sva_lock);
- /* Search for an existing domain. */
- domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
- IOMMU_DOMAIN_SVA);
- if (IS_ERR(domain)) {
- ret = PTR_ERR(domain);
+ if (!handle) {
+ ret = -ENOMEM;
goto out_unlock;
}
- if (domain) {
- domain->users++;
- goto out;
+ /* Search for an existing domain. */
+ list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next) {
+ ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid);
+ if (!ret) {
+ domain->users++;
+ goto out;
+ }
}
/* Allocate a new domain and set it on device pasid. */
@@ -92,23 +104,23 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
goto out_unlock;
}
- ret = iommu_attach_device_pasid(domain, dev, mm->pasid);
+ ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid);
if (ret)
goto out_free_domain;
domain->users = 1;
+ list_add(&domain->next, &mm->iommu_mm->sva_domains);
+
out:
mutex_unlock(&iommu_sva_lock);
handle->dev = dev;
handle->domain = domain;
-
return handle;
out_free_domain:
iommu_domain_free(domain);
+ kfree(handle);
out_unlock:
mutex_unlock(&iommu_sva_lock);
- kfree(handle);
-
return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
@@ -124,12 +136,13 @@ EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
void iommu_sva_unbind_device(struct iommu_sva *handle)
{
struct iommu_domain *domain = handle->domain;
- ioasid_t pasid = domain->mm->pasid;
+ struct iommu_mm_data *iommu_mm = domain->mm->iommu_mm;
struct device *dev = handle->dev;
mutex_lock(&iommu_sva_lock);
+ iommu_detach_device_pasid(domain, dev, iommu_mm->pasid);
if (--domain->users == 0) {
- iommu_detach_device_pasid(domain, dev, pasid);
+ list_del(&domain->next);
iommu_domain_free(domain);
}
mutex_unlock(&iommu_sva_lock);
@@ -205,8 +218,11 @@ iommu_sva_handle_iopf(struct iommu_fault *fault, void *data)
void mm_pasid_drop(struct mm_struct *mm)
{
- if (likely(!mm_valid_pasid(mm)))
+ struct iommu_mm_data *iommu_mm = mm->iommu_mm;
+
+ if (!iommu_mm)
return;
- iommu_free_global_pasid(mm->pasid);
+ iommu_free_global_pasid(iommu_mm->pasid);
+ kfree(iommu_mm);
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a807182c3d2e..98b199603588 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -113,6 +113,11 @@ struct iommu_domain {
struct { /* IOMMU_DOMAIN_SVA */
struct mm_struct *mm;
int users;
+ /*
+ * Next iommu_domain in mm->iommu_mm->sva-domains list
+ * protected by iommu_sva_lock.
+ */
+ struct list_head next;
};
};
};
@@ -1197,16 +1202,28 @@ static inline bool tegra_dev_iommu_get_stream_id(struct device *dev, u32 *stream
#ifdef CONFIG_IOMMU_MM_DATA
static inline void mm_pasid_init(struct mm_struct *mm)
{
- mm->pasid = IOMMU_PASID_INVALID;
+ /*
+ * During dup_mm(), a new mm will be memcpy'd from an old one and that makes
+ * the new mm and the old one point to a same iommu_mm instance. When either
+ * one of the two mms gets released, the iommu_mm instance is freed, leaving
+ * the other mm running into a use-after-free/double-free problem. To avoid
+ * the problem, zeroing the iommu_mm pointer of a new mm is needed here.
+ */
+ mm->iommu_mm = NULL;
}
+
static inline bool mm_valid_pasid(struct mm_struct *mm)
{
- return mm->pasid != IOMMU_PASID_INVALID;
+ return READ_ONCE(mm->iommu_mm);
}
static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
{
- return mm->pasid;
+ struct iommu_mm_data *iommu_mm = READ_ONCE(mm->iommu_mm);
+
+ if (!iommu_mm)
+ return IOMMU_PASID_INVALID;
+ return iommu_mm->pasid;
}
void mm_pasid_drop(struct mm_struct *mm);
--
2.39.3
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2023-10-27 0:05 ` [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains Tina Zhang
@ 2024-02-20 16:26 ` Zhangfei Gao
2024-02-20 23:58 ` Zhang, Tina
0 siblings, 1 reply; 24+ messages in thread
From: Zhangfei Gao @ 2024-02-20 16:26 UTC (permalink / raw)
To: Tina Zhang
Cc: iommu, linux-kernel, David Woodhouse, Lu Baolu, Joerg Roedel,
Will Deacon, Robin Murphy, Jason Gunthorpe, Kevin Tian,
Nicolin Chen, Michael Shavit, Vasant Hegde, Jason Gunthorpe
Hi, Tina
On Fri, 27 Oct 2023 at 08:06, Tina Zhang <tina.zhang@intel.com> 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>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/iommu-sva.c | 92 +++++++++++++++++++++++----------------
> include/linux/iommu.h | 23 ++++++++--
> 2 files changed, 74 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index 4a2f5699747f..5175e8d85247 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -12,32 +12,42 @@
> static DEFINE_MUTEX(iommu_sva_lock);
>
> /* Allocate a PASID for the mm within range (inclusive) */
> -static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
> +static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct device *dev)
> {
> + struct iommu_mm_data *iommu_mm;
> ioasid_t pasid;
> - int ret = 0;
> +
> + lockdep_assert_held(&iommu_sva_lock);
>
> if (!arch_pgtable_dma_compat(mm))
> - return -EBUSY;
> + return ERR_PTR(-EBUSY);
>
> - mutex_lock(&iommu_sva_lock);
> + iommu_mm = mm->iommu_mm;
> /* Is a PASID already associated with this mm? */
> - if (mm_valid_pasid(mm)) {
> - if (mm->pasid >= dev->iommu->max_pasids)
> - ret = -EOVERFLOW;
> - goto out;
> + if (iommu_mm) {
> + if (iommu_mm->pasid >= dev->iommu->max_pasids)
> + return ERR_PTR(-EOVERFLOW);
> + return iommu_mm;
> }
>
> + iommu_mm = kzalloc(sizeof(struct iommu_mm_data), GFP_KERNEL);
> + if (!iommu_mm)
> + return ERR_PTR(-ENOMEM);
> +
> pasid = iommu_alloc_global_pasid(dev);
> if (pasid == IOMMU_PASID_INVALID) {
> - ret = -ENOSPC;
> - goto out;
> + kfree(iommu_mm);
> + return ERR_PTR(-ENOSPC);
> }
> - mm->pasid = pasid;
> - ret = 0;
> -out:
> - mutex_unlock(&iommu_sva_lock);
> - return ret;
> + iommu_mm->pasid = pasid;
> + INIT_LIST_HEAD(&iommu_mm->sva_domains);
> + /*
> + * Make sure the write to mm->iommu_mm is not reordered in front of
> + * initialization to iommu_mm fields. If it does, readers may see a
> + * valid iommu_mm with uninitialized values.
> + */
> + smp_store_release(&mm->iommu_mm, iommu_mm);
> + return iommu_mm;
> }
>
> /**
> @@ -58,31 +68,33 @@ static int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
> */
> struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
> {
> + struct iommu_mm_data *iommu_mm;
> struct iommu_domain *domain;
> struct iommu_sva *handle;
> int ret;
>
> + mutex_lock(&iommu_sva_lock);
> +
> /* Allocate mm->pasid if necessary. */
> - ret = iommu_sva_alloc_pasid(mm, dev);
> - if (ret)
> - return ERR_PTR(ret);
> + iommu_mm = iommu_alloc_mm_data(mm, dev);
> + if (IS_ERR(iommu_mm)) {
> + ret = PTR_ERR(iommu_mm);
> + goto out_unlock;
> + }
>
> handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> - if (!handle)
> - return ERR_PTR(-ENOMEM);
> -
> - mutex_lock(&iommu_sva_lock);
> - /* Search for an existing domain. */
> - domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
> - IOMMU_DOMAIN_SVA);
> - if (IS_ERR(domain)) {
> - ret = PTR_ERR(domain);
> + if (!handle) {
> + ret = -ENOMEM;
> goto out_unlock;
> }
>
> - if (domain) {
> - domain->users++;
> - goto out;
Our multi bind test case broke since 6.8-rc1.
The test case can use same domain & pasid, return different handle,
6.7 simply domain->users ++ and return.
> + /* Search for an existing domain. */
> + list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next) {
> + ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid);
Now iommu_attach_device_pasid return BUSY since the same pasid.
And then iommu_sva_bind_device attach ret=-16
> + if (!ret) {
Simply tried if (!ret || ret == -EBUSY)
The test passes, but report waring
WARNING: CPU: 12 PID: 2992 at drivers/iommu/iommu.c:3591
iommu_detach_device_pasid+0xa4/0xd0
Will check more tomorrow.
> + domain->users++;
> + goto out;
> + }
> }
>
Thanks
^ permalink raw reply [flat|nested] 24+ messages in thread* RE: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2024-02-20 16:26 ` Zhangfei Gao
@ 2024-02-20 23:58 ` Zhang, Tina
2024-02-21 1:28 ` Zhangfei Gao
0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Tina @ 2024-02-20 23:58 UTC (permalink / raw)
To: Zhangfei Gao
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Lu Baolu, Joerg Roedel, Will Deacon,
Robin Murphy, Jason Gunthorpe, Tian, Kevin, Nicolin Chen,
Michael Shavit, Vasant Hegde, Jason Gunthorpe
Hi Zhangfei,
> -----Original Message-----
> From: Zhangfei Gao <zhangfei.gao@linaro.org>
> Sent: Wednesday, February 21, 2024 12:27 AM
> To: Zhang, Tina <tina.zhang@intel.com>
> Cc: iommu@lists.linux.dev; linux-kernel@vger.kernel.org; David Woodhouse
> <dwmw2@infradead.org>; Lu Baolu <baolu.lu@linux.intel.com>; Joerg
> Roedel <joro@8bytes.org>; Will Deacon <will@kernel.org>; Robin Murphy
> <robin.murphy@arm.com>; Jason Gunthorpe <jgg@ziepe.ca>; Tian, Kevin
> <kevin.tian@intel.com>; Nicolin Chen <nicolinc@nvidia.com>; Michael Shavit
> <mshavit@google.com>; Vasant Hegde <vasant.hegde@amd.com>; Jason
> Gunthorpe <jgg@nvidia.com>
> Subject: Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva
> domains
>
> Hi, Tina
>
> On Fri, 27 Oct 2023 at 08:06, Tina Zhang <tina.zhang@intel.com> 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>
> > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> > Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> > Signed-off-by: Tina Zhang <tina.zhang@intel.com>
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> > drivers/iommu/iommu-sva.c | 92 +++++++++++++++++++++++----------------
> > include/linux/iommu.h | 23 ++++++++--
> > 2 files changed, 74 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> > index 4a2f5699747f..5175e8d85247 100644
> > --- a/drivers/iommu/iommu-sva.c
> > +++ b/drivers/iommu/iommu-sva.c
> > @@ -12,32 +12,42 @@
> > static DEFINE_MUTEX(iommu_sva_lock);
> >
> > /* Allocate a PASID for the mm within range (inclusive) */ -static
> > int iommu_sva_alloc_pasid(struct mm_struct *mm, struct device *dev)
> > +static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct
> > +*mm, struct device *dev)
> > {
> > + struct iommu_mm_data *iommu_mm;
> > ioasid_t pasid;
> > - int ret = 0;
> > +
> > + lockdep_assert_held(&iommu_sva_lock);
> >
> > if (!arch_pgtable_dma_compat(mm))
> > - return -EBUSY;
> > + return ERR_PTR(-EBUSY);
> >
> > - mutex_lock(&iommu_sva_lock);
> > + iommu_mm = mm->iommu_mm;
> > /* Is a PASID already associated with this mm? */
> > - if (mm_valid_pasid(mm)) {
> > - if (mm->pasid >= dev->iommu->max_pasids)
> > - ret = -EOVERFLOW;
> > - goto out;
> > + if (iommu_mm) {
> > + if (iommu_mm->pasid >= dev->iommu->max_pasids)
> > + return ERR_PTR(-EOVERFLOW);
> > + return iommu_mm;
> > }
> >
> > + iommu_mm = kzalloc(sizeof(struct iommu_mm_data), GFP_KERNEL);
> > + if (!iommu_mm)
> > + return ERR_PTR(-ENOMEM);
> > +
> > pasid = iommu_alloc_global_pasid(dev);
> > if (pasid == IOMMU_PASID_INVALID) {
> > - ret = -ENOSPC;
> > - goto out;
> > + kfree(iommu_mm);
> > + return ERR_PTR(-ENOSPC);
> > }
> > - mm->pasid = pasid;
> > - ret = 0;
> > -out:
> > - mutex_unlock(&iommu_sva_lock);
> > - return ret;
> > + iommu_mm->pasid = pasid;
> > + INIT_LIST_HEAD(&iommu_mm->sva_domains);
> > + /*
> > + * Make sure the write to mm->iommu_mm is not reordered in front
> of
> > + * initialization to iommu_mm fields. If it does, readers may see a
> > + * valid iommu_mm with uninitialized values.
> > + */
> > + smp_store_release(&mm->iommu_mm, iommu_mm);
> > + return iommu_mm;
> > }
> >
> > /**
> > @@ -58,31 +68,33 @@ static int iommu_sva_alloc_pasid(struct mm_struct
> *mm, struct device *dev)
> > */
> > struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct
> > mm_struct *mm) {
> > + struct iommu_mm_data *iommu_mm;
> > struct iommu_domain *domain;
> > struct iommu_sva *handle;
> > int ret;
> >
> > + mutex_lock(&iommu_sva_lock);
> > +
> > /* Allocate mm->pasid if necessary. */
> > - ret = iommu_sva_alloc_pasid(mm, dev);
> > - if (ret)
> > - return ERR_PTR(ret);
> > + iommu_mm = iommu_alloc_mm_data(mm, dev);
> > + if (IS_ERR(iommu_mm)) {
> > + ret = PTR_ERR(iommu_mm);
> > + goto out_unlock;
> > + }
> >
> > handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> > - if (!handle)
> > - return ERR_PTR(-ENOMEM);
> > -
> > - mutex_lock(&iommu_sva_lock);
> > - /* Search for an existing domain. */
> > - domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
> > - IOMMU_DOMAIN_SVA);
> > - if (IS_ERR(domain)) {
> > - ret = PTR_ERR(domain);
> > + if (!handle) {
> > + ret = -ENOMEM;
> > goto out_unlock;
> > }
> >
> > - if (domain) {
> > - domain->users++;
> > - goto out;
>
> Our multi bind test case broke since 6.8-rc1.
> The test case can use same domain & pasid, return different handle,
> 6.7 simply domain->users ++ and return.
>
> > + /* Search for an existing domain. */
> > + list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next)
> {
> > + ret = iommu_attach_device_pasid(domain, dev,
> > + iommu_mm->pasid);
>
> Now iommu_attach_device_pasid return BUSY since the same pasid.
> And then iommu_sva_bind_device attach ret=-16
Sounds like the test case tries to bind a device to a same mm multiple times without unbinding the device and the expectation is that it can always return a valid handle to pass the test. Right?
Regards,
-Tina
>
> > + if (!ret) {
>
> Simply tried if (!ret || ret == -EBUSY)
> The test passes, but report waring
> WARNING: CPU: 12 PID: 2992 at drivers/iommu/iommu.c:3591
> iommu_detach_device_pasid+0xa4/0xd0
>
> Will check more tomorrow.
>
> > + domain->users++;
> > + goto out;
> > + }
> > }
> >
>
> Thanks
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2024-02-20 23:58 ` Zhang, Tina
@ 2024-02-21 1:28 ` Zhangfei Gao
2024-02-21 1:53 ` Zhangfei Gao
2024-02-21 2:06 ` Baolu Lu
0 siblings, 2 replies; 24+ messages in thread
From: Zhangfei Gao @ 2024-02-21 1:28 UTC (permalink / raw)
To: Zhang, Tina
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Lu Baolu, Joerg Roedel, Will Deacon,
Robin Murphy, Jason Gunthorpe, Tian, Kevin, Nicolin Chen,
Michael Shavit, Vasant Hegde, Jason Gunthorpe
Hi, Tina
On Wed, 21 Feb 2024 at 07:58, Zhang, Tina <tina.zhang@intel.com> wrote:
> > > struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct
> > > mm_struct *mm) {
> > > + struct iommu_mm_data *iommu_mm;
> > > struct iommu_domain *domain;
> > > struct iommu_sva *handle;
> > > int ret;
> > >
> > > + mutex_lock(&iommu_sva_lock);
> > > +
> > > /* Allocate mm->pasid if necessary. */
> > > - ret = iommu_sva_alloc_pasid(mm, dev);
> > > - if (ret)
> > > - return ERR_PTR(ret);
> > > + iommu_mm = iommu_alloc_mm_data(mm, dev);
> > > + if (IS_ERR(iommu_mm)) {
> > > + ret = PTR_ERR(iommu_mm);
> > > + goto out_unlock;
> > > + }
> > >
> > > handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> > > - if (!handle)
> > > - return ERR_PTR(-ENOMEM);
> > > -
> > > - mutex_lock(&iommu_sva_lock);
> > > - /* Search for an existing domain. */
> > > - domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
> > > - IOMMU_DOMAIN_SVA);
> > > - if (IS_ERR(domain)) {
> > > - ret = PTR_ERR(domain);
> > > + if (!handle) {
> > > + ret = -ENOMEM;
> > > goto out_unlock;
> > > }
> > >
> > > - if (domain) {
> > > - domain->users++;
> > > - goto out;
> >
> > Our multi bind test case broke since 6.8-rc1.
> > The test case can use same domain & pasid, return different handle,
> > 6.7 simply domain->users ++ and return.
> >
> > > + /* Search for an existing domain. */
> > > + list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next)
> > {
> > > + ret = iommu_attach_device_pasid(domain, dev,
> > > + iommu_mm->pasid);
> >
> > Now iommu_attach_device_pasid return BUSY since the same pasid.
> > And then iommu_sva_bind_device attach ret=-16
> Sounds like the test case tries to bind a device to a same mm multiple times without unbinding the device and the expectation is that it can always return a valid handle to pass the test. Right?
Yes
The device can bind to the same mm multi-times and return different handle,
Since the refcount, no need to unbind and bind sequently,
The unbind can happen later with the handle.
Thanks
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2024-02-21 1:28 ` Zhangfei Gao
@ 2024-02-21 1:53 ` Zhangfei Gao
2024-02-21 2:06 ` Baolu Lu
1 sibling, 0 replies; 24+ messages in thread
From: Zhangfei Gao @ 2024-02-21 1:53 UTC (permalink / raw)
To: Zhang, Tina
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Lu Baolu, Joerg Roedel, Will Deacon,
Robin Murphy, Jason Gunthorpe, Tian, Kevin, Nicolin Chen,
Michael Shavit, Vasant Hegde, Jason Gunthorpe
On Wed, 21 Feb 2024 at 09:28, Zhangfei Gao <zhangfei.gao@linaro.org> wrote:
>
> Hi, Tina
>
> On Wed, 21 Feb 2024 at 07:58, Zhang, Tina <tina.zhang@intel.com> wrote:
>
> > > > struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct
> > > > mm_struct *mm) {
> > > > + struct iommu_mm_data *iommu_mm;
> > > > struct iommu_domain *domain;
> > > > struct iommu_sva *handle;
> > > > int ret;
> > > >
> > > > + mutex_lock(&iommu_sva_lock);
> > > > +
> > > > /* Allocate mm->pasid if necessary. */
> > > > - ret = iommu_sva_alloc_pasid(mm, dev);
> > > > - if (ret)
> > > > - return ERR_PTR(ret);
> > > > + iommu_mm = iommu_alloc_mm_data(mm, dev);
> > > > + if (IS_ERR(iommu_mm)) {
> > > > + ret = PTR_ERR(iommu_mm);
> > > > + goto out_unlock;
> > > > + }
> > > >
> > > > handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> > > > - if (!handle)
> > > > - return ERR_PTR(-ENOMEM);
> > > > -
> > > > - mutex_lock(&iommu_sva_lock);
> > > > - /* Search for an existing domain. */
> > > > - domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
> > > > - IOMMU_DOMAIN_SVA);
> > > > - if (IS_ERR(domain)) {
> > > > - ret = PTR_ERR(domain);
> > > > + if (!handle) {
> > > > + ret = -ENOMEM;
> > > > goto out_unlock;
> > > > }
> > > >
> > > > - if (domain) {
> > > > - domain->users++;
> > > > - goto out;
> > >
> > > Our multi bind test case broke since 6.8-rc1.
> > > The test case can use same domain & pasid, return different handle,
> > > 6.7 simply domain->users ++ and return.
> > >
> > > > + /* Search for an existing domain. */
> > > > + list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next)
> > > {
> > > > + ret = iommu_attach_device_pasid(domain, dev,
> > > > + iommu_mm->pasid);
> > >
> > > Now iommu_attach_device_pasid return BUSY since the same pasid.
> > > And then iommu_sva_bind_device attach ret=-16
> > Sounds like the test case tries to bind a device to a same mm multiple times without unbinding the device and the expectation is that it can always return a valid handle to pass the test. Right?
>
> Yes
>
> The device can bind to the same mm multi-times and return different handle,
> Since the refcount, no need to unbind and bind sequently,
> The unbind can happen later with the handle.
With this diff can solve the issue, what's your suggestion?
@@ -88,10 +94,12 @@ struct iommu_sva *iommu_sva_bind_device(struct
device *dev, struct mm_struct *mm
/* Search for an existing domain. */
list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next) {
ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid);
- if (!ret) {
+ if (!ret || ret == -EBUSY) {
domain->users++;
goto out;
}
@@ -141,8 +151,8 @@ void iommu_sva_unbind_device(struct iommu_sva *handle)
struct device *dev = handle->dev;
mutex_lock(&iommu_sva_lock);
- iommu_detach_device_pasid(domain, dev, iommu_mm->pasid);
if (--domain->users == 0) {
+ iommu_detach_device_pasid(domain, dev, iommu_mm->pasid);
list_del(&domain->next);
iommu_domain_free(domain);
}
Thanks
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2024-02-21 1:28 ` Zhangfei Gao
2024-02-21 1:53 ` Zhangfei Gao
@ 2024-02-21 2:06 ` Baolu Lu
2024-02-21 2:45 ` Zhangfei Gao
1 sibling, 1 reply; 24+ messages in thread
From: Baolu Lu @ 2024-02-21 2:06 UTC (permalink / raw)
To: Zhangfei Gao, Zhang, Tina
Cc: baolu.lu, iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Joerg Roedel, Will Deacon, Robin Murphy,
Jason Gunthorpe, Tian, Kevin, Nicolin Chen, Michael Shavit,
Vasant Hegde, Jason Gunthorpe
On 2024/2/21 9:28, Zhangfei Gao wrote:
> On Wed, 21 Feb 2024 at 07:58, Zhang, Tina<tina.zhang@intel.com> wrote:
>
>>>> struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct
>>>> mm_struct *mm) {
>>>> + struct iommu_mm_data *iommu_mm;
>>>> struct iommu_domain *domain;
>>>> struct iommu_sva *handle;
>>>> int ret;
>>>>
>>>> + mutex_lock(&iommu_sva_lock);
>>>> +
>>>> /* Allocate mm->pasid if necessary. */
>>>> - ret = iommu_sva_alloc_pasid(mm, dev);
>>>> - if (ret)
>>>> - return ERR_PTR(ret);
>>>> + iommu_mm = iommu_alloc_mm_data(mm, dev);
>>>> + if (IS_ERR(iommu_mm)) {
>>>> + ret = PTR_ERR(iommu_mm);
>>>> + goto out_unlock;
>>>> + }
>>>>
>>>> handle = kzalloc(sizeof(*handle), GFP_KERNEL);
>>>> - if (!handle)
>>>> - return ERR_PTR(-ENOMEM);
>>>> -
>>>> - mutex_lock(&iommu_sva_lock);
>>>> - /* Search for an existing domain. */
>>>> - domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
>>>> - IOMMU_DOMAIN_SVA);
>>>> - if (IS_ERR(domain)) {
>>>> - ret = PTR_ERR(domain);
>>>> + if (!handle) {
>>>> + ret = -ENOMEM;
>>>> goto out_unlock;
>>>> }
>>>>
>>>> - if (domain) {
>>>> - domain->users++;
>>>> - goto out;
>>> Our multi bind test case broke since 6.8-rc1.
>>> The test case can use same domain & pasid, return different handle,
>>> 6.7 simply domain->users ++ and return.
>>>
>>>> + /* Search for an existing domain. */
>>>> + list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next)
>>> {
>>>> + ret = iommu_attach_device_pasid(domain, dev,
>>>> + iommu_mm->pasid);
>>> Now iommu_attach_device_pasid return BUSY since the same pasid.
>>> And then iommu_sva_bind_device attach ret=-16
>> Sounds like the test case tries to bind a device to a same mm multiple times without unbinding the device and the expectation is that it can always return a valid handle to pass the test. Right?
> Yes
>
> The device can bind to the same mm multi-times and return different handle,
> Since the refcount, no need to unbind and bind sequently,
> The unbind can happen later with the handle.
Is there any real use case to bind an mm to the pasid of a device
multiple times? If there are cases, is it better to handle this in the
uacce driver?
From iommu core's perspective, it doesn't make sense to attach the same
domain to the same device (or pasid) multiple times.
Best regards,
baolu
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2024-02-21 2:06 ` Baolu Lu
@ 2024-02-21 2:45 ` Zhangfei Gao
2024-02-21 3:52 ` Baolu Lu
2024-02-21 7:41 ` Zhang, Tina
0 siblings, 2 replies; 24+ messages in thread
From: Zhangfei Gao @ 2024-02-21 2:45 UTC (permalink / raw)
To: Baolu Lu
Cc: Zhang, Tina, iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Joerg Roedel, Will Deacon, Robin Murphy,
Jason Gunthorpe, Tian, Kevin, Nicolin Chen, Michael Shavit,
Vasant Hegde, Jason Gunthorpe, Jean-Philippe Brucker, Hao Fang
On Wed, 21 Feb 2024 at 10:06, Baolu Lu <baolu.lu@linux.intel.com> wrote:
>
> On 2024/2/21 9:28, Zhangfei Gao wrote:
> > On Wed, 21 Feb 2024 at 07:58, Zhang, Tina<tina.zhang@intel.com> wrote:
> >
> >>>> struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct
> >>>> mm_struct *mm) {
> >>>> + struct iommu_mm_data *iommu_mm;
> >>>> struct iommu_domain *domain;
> >>>> struct iommu_sva *handle;
> >>>> int ret;
> >>>>
> >>>> + mutex_lock(&iommu_sva_lock);
> >>>> +
> >>>> /* Allocate mm->pasid if necessary. */
> >>>> - ret = iommu_sva_alloc_pasid(mm, dev);
> >>>> - if (ret)
> >>>> - return ERR_PTR(ret);
> >>>> + iommu_mm = iommu_alloc_mm_data(mm, dev);
> >>>> + if (IS_ERR(iommu_mm)) {
> >>>> + ret = PTR_ERR(iommu_mm);
> >>>> + goto out_unlock;
> >>>> + }
> >>>>
> >>>> handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> >>>> - if (!handle)
> >>>> - return ERR_PTR(-ENOMEM);
> >>>> -
> >>>> - mutex_lock(&iommu_sva_lock);
> >>>> - /* Search for an existing domain. */
> >>>> - domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
> >>>> - IOMMU_DOMAIN_SVA);
> >>>> - if (IS_ERR(domain)) {
> >>>> - ret = PTR_ERR(domain);
> >>>> + if (!handle) {
> >>>> + ret = -ENOMEM;
> >>>> goto out_unlock;
> >>>> }
> >>>>
> >>>> - if (domain) {
> >>>> - domain->users++;
> >>>> - goto out;
> >>> Our multi bind test case broke since 6.8-rc1.
> >>> The test case can use same domain & pasid, return different handle,
> >>> 6.7 simply domain->users ++ and return.
> >>>
> >>>> + /* Search for an existing domain. */
> >>>> + list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next)
> >>> {
> >>>> + ret = iommu_attach_device_pasid(domain, dev,
> >>>> + iommu_mm->pasid);
> >>> Now iommu_attach_device_pasid return BUSY since the same pasid.
> >>> And then iommu_sva_bind_device attach ret=-16
> >> Sounds like the test case tries to bind a device to a same mm multiple times without unbinding the device and the expectation is that it can always return a valid handle to pass the test. Right?
> > Yes
> >
> > The device can bind to the same mm multi-times and return different handle,
> > Since the refcount, no need to unbind and bind sequently,
> > The unbind can happen later with the handle.
>
> Is there any real use case to bind an mm to the pasid of a device
> multiple times? If there are cases, is it better to handle this in the
> uacce driver?
Yes, it is required for multi-thread, the device can provide
multi-queue to speed up.
>
> From iommu core's perspective, it doesn't make sense to attach the same
> domain to the same device (or pasid) multiple times.
But is it the refcount domain->user++ used for?
Is there any reason not doing this.
Thanks
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2024-02-21 2:45 ` Zhangfei Gao
@ 2024-02-21 3:52 ` Baolu Lu
2024-02-21 6:26 ` Zhangfei Gao
2024-02-21 7:41 ` Zhang, Tina
1 sibling, 1 reply; 24+ messages in thread
From: Baolu Lu @ 2024-02-21 3:52 UTC (permalink / raw)
To: Zhangfei Gao
Cc: baolu.lu, Zhang, Tina, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, David Woodhouse, Joerg Roedel,
Will Deacon, Robin Murphy, Jason Gunthorpe, Tian, Kevin,
Nicolin Chen, Michael Shavit, Vasant Hegde, Jason Gunthorpe,
Jean-Philippe Brucker, Hao Fang
On 2024/2/21 10:45, Zhangfei Gao wrote:
> On Wed, 21 Feb 2024 at 10:06, Baolu Lu<baolu.lu@linux.intel.com>
> wrote:
>> On 2024/2/21 9:28, Zhangfei Gao wrote:
>>> On Wed, 21 Feb 2024 at 07:58, Zhang, Tina<tina.zhang@intel.com>
>>> wrote:
>>>
>>>>>> struct iommu_sva *iommu_sva_bind_device(struct device
>>>>>> *dev, struct mm_struct *mm) { + struct
>>>>>> iommu_mm_data *iommu_mm; struct iommu_domain *domain;
>>>>>> struct iommu_sva *handle; int ret;
>>>>>>
>>>>>> + mutex_lock(&iommu_sva_lock); + /* Allocate
>>>>>> mm->pasid if necessary. */ - ret =
>>>>>> iommu_sva_alloc_pasid(mm, dev); - if (ret) - return
>>>>>> ERR_PTR(ret); + iommu_mm = iommu_alloc_mm_data(mm,
>>>>>> dev); + if (IS_ERR(iommu_mm)) { + ret =
>>>>>> PTR_ERR(iommu_mm); + goto out_unlock; + }
>>>>>>
>>>>>> handle = kzalloc(sizeof(*handle), GFP_KERNEL); - if
>>>>>> (!handle) - return ERR_PTR(-ENOMEM); - -
>>>>>> mutex_lock(&iommu_sva_lock); - /* Search for an
>>>>>> existing domain. */ - domain =
>>>>>> iommu_get_domain_for_dev_pasid(dev, mm->pasid, -
>>>>>> IOMMU_DOMAIN_SVA); - if (IS_ERR(domain)) { - ret =
>>>>>> PTR_ERR(domain); + if (!handle) { + ret = -ENOMEM;
>>>>>> goto out_unlock; }
>>>>>>
>>>>>> - if (domain) { - domain->users++; -
>>>>>> goto out;
>>>>> Our multi bind test case broke since 6.8-rc1. The test case
>>>>> can use same domain & pasid, return different handle, 6.7
>>>>> simply domain->users ++ and return.
>>>>>
>>>>>> + /* Search for an existing domain. */ +
>>>>>> list_for_each_entry(domain, &mm->iommu_mm->sva_domains,
>>>>>> next)
>>>>> {
>>>>>> + ret = iommu_attach_device_pasid(domain,
>>>>>> dev, + iommu_mm->pasid);
>>>>> Now iommu_attach_device_pasid return BUSY since the same
>>>>> pasid. And then iommu_sva_bind_device attach ret=-16
>>>> Sounds like the test case tries to bind a device to a same mm
>>>> multiple times without unbinding the device and the
>>>> expectation is that it can always return a valid handle to pass
>>>> the test. Right?
>>> Yes
>>>
>>> The device can bind to the same mm multi-times and return
>>> different handle, Since the refcount, no need to unbind and bind
>>> sequently, The unbind can happen later with the handle.
>> Is there any real use case to bind an mm to the pasid of a device
>> multiple times? If there are cases, is it better to handle this in
>> the uacce driver?
> Yes, it is required for multi-thread, the device can provide
> multi-queue to speed up.
>
>> From iommu core's perspective, it doesn't make sense to attach the
>> same domain to the same device (or pasid) multiple times.
> But is it the refcount domain->user++ used for? Is there any reason
> not doing this.
I was just thinking about whether to do this in the iommu core, or in
the upper layers, like uacce or iommufd. It seems that there is no need
to attach a domain to a device or pasid again if it has already been
attached.
Best regards,
baolu
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2024-02-21 3:52 ` Baolu Lu
@ 2024-02-21 6:26 ` Zhangfei Gao
0 siblings, 0 replies; 24+ messages in thread
From: Zhangfei Gao @ 2024-02-21 6:26 UTC (permalink / raw)
To: Baolu Lu
Cc: Zhang, Tina, iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Joerg Roedel, Will Deacon, Robin Murphy,
Jason Gunthorpe, Tian, Kevin, Nicolin Chen, Michael Shavit,
Vasant Hegde, Jason Gunthorpe, Jean-Philippe Brucker, Hao Fang
On Wed, 21 Feb 2024 at 11:52, Baolu Lu <baolu.lu@linux.intel.com> wrote:
>
> On 2024/2/21 10:45, Zhangfei Gao wrote:
> > On Wed, 21 Feb 2024 at 10:06, Baolu Lu<baolu.lu@linux.intel.com>
> > wrote:
> >> On 2024/2/21 9:28, Zhangfei Gao wrote:
> >>> On Wed, 21 Feb 2024 at 07:58, Zhang, Tina<tina.zhang@intel.com>
> >>> wrote:
> >>>
> >>>>>> struct iommu_sva *iommu_sva_bind_device(struct device
> >>>>>> *dev, struct mm_struct *mm) { + struct
> >>>>>> iommu_mm_data *iommu_mm; struct iommu_domain *domain;
> >>>>>> struct iommu_sva *handle; int ret;
> >>>>>>
> >>>>>> + mutex_lock(&iommu_sva_lock); + /* Allocate
> >>>>>> mm->pasid if necessary. */ - ret =
> >>>>>> iommu_sva_alloc_pasid(mm, dev); - if (ret) - return
> >>>>>> ERR_PTR(ret); + iommu_mm = iommu_alloc_mm_data(mm,
> >>>>>> dev); + if (IS_ERR(iommu_mm)) { + ret =
> >>>>>> PTR_ERR(iommu_mm); + goto out_unlock; + }
> >>>>>>
> >>>>>> handle = kzalloc(sizeof(*handle), GFP_KERNEL); - if
> >>>>>> (!handle) - return ERR_PTR(-ENOMEM); - -
> >>>>>> mutex_lock(&iommu_sva_lock); - /* Search for an
> >>>>>> existing domain. */ - domain =
> >>>>>> iommu_get_domain_for_dev_pasid(dev, mm->pasid, -
> >>>>>> IOMMU_DOMAIN_SVA); - if (IS_ERR(domain)) { - ret =
> >>>>>> PTR_ERR(domain); + if (!handle) { + ret = -ENOMEM;
> >>>>>> goto out_unlock; }
> >>>>>>
> >>>>>> - if (domain) { - domain->users++; -
> >>>>>> goto out;
> >>>>> Our multi bind test case broke since 6.8-rc1. The test case
> >>>>> can use same domain & pasid, return different handle, 6.7
> >>>>> simply domain->users ++ and return.
> >>>>>
> >>>>>> + /* Search for an existing domain. */ +
> >>>>>> list_for_each_entry(domain, &mm->iommu_mm->sva_domains,
> >>>>>> next)
> >>>>> {
> >>>>>> + ret = iommu_attach_device_pasid(domain,
> >>>>>> dev, + iommu_mm->pasid);
> >>>>> Now iommu_attach_device_pasid return BUSY since the same
> >>>>> pasid. And then iommu_sva_bind_device attach ret=-16
> >>>> Sounds like the test case tries to bind a device to a same mm
> >>>> multiple times without unbinding the device and the
> >>>> expectation is that it can always return a valid handle to pass
> >>>> the test. Right?
> >>> Yes
> >>>
> >>> The device can bind to the same mm multi-times and return
> >>> different handle, Since the refcount, no need to unbind and bind
> >>> sequently, The unbind can happen later with the handle.
> >> Is there any real use case to bind an mm to the pasid of a device
> >> multiple times? If there are cases, is it better to handle this in
> >> the uacce driver?
> > Yes, it is required for multi-thread, the device can provide
> > multi-queue to speed up.
> >
> >> From iommu core's perspective, it doesn't make sense to attach the
> >> same domain to the same device (or pasid) multiple times.
> > But is it the refcount domain->user++ used for? Is there any reason
> > not doing this.
>
> I was just thinking about whether to do this in the iommu core, or in
> the upper layers, like uacce or iommufd. It seems that there is no need
> to attach a domain to a device or pasid again if it has already been
> attached.
It would be more complicated since the return handle can be used to
distinguish different queues of the device.
I think domain->user should handle this case as before.
Anyway, I have sent a patch to get more feedback.
Thanks
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2024-02-21 2:45 ` Zhangfei Gao
2024-02-21 3:52 ` Baolu Lu
@ 2024-02-21 7:41 ` Zhang, Tina
2024-02-21 8:01 ` Zhangfei Gao
1 sibling, 1 reply; 24+ messages in thread
From: Zhang, Tina @ 2024-02-21 7:41 UTC (permalink / raw)
To: Zhangfei Gao, Baolu Lu
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Joerg Roedel, Will Deacon, Robin Murphy,
Jason Gunthorpe, Tian, Kevin, Nicolin Chen, Michael Shavit,
Vasant Hegde, Jason Gunthorpe, Jean-Philippe Brucker, Hao Fang
Hi,
> -----Original Message-----
> From: Zhangfei Gao <zhangfei.gao@linaro.org>
> Sent: Wednesday, February 21, 2024 10:45 AM
> To: Baolu Lu <baolu.lu@linux.intel.com>
> Cc: Zhang, Tina <tina.zhang@intel.com>; iommu@lists.linux.dev; linux-
> kernel@vger.kernel.org; David Woodhouse <dwmw2@infradead.org>; Joerg
> Roedel <joro@8bytes.org>; Will Deacon <will@kernel.org>; Robin Murphy
> <robin.murphy@arm.com>; Jason Gunthorpe <jgg@ziepe.ca>; Tian, Kevin
> <kevin.tian@intel.com>; Nicolin Chen <nicolinc@nvidia.com>; Michael Shavit
> <mshavit@google.com>; Vasant Hegde <vasant.hegde@amd.com>; Jason
> Gunthorpe <jgg@nvidia.com>; Jean-Philippe Brucker <jean-
> philippe@linaro.org>; Hao Fang <fanghao11@huawei.com>
> Subject: Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva
> domains
>
> On Wed, 21 Feb 2024 at 10:06, Baolu Lu <baolu.lu@linux.intel.com> wrote:
> >
> > On 2024/2/21 9:28, Zhangfei Gao wrote:
> > > On Wed, 21 Feb 2024 at 07:58, Zhang, Tina<tina.zhang@intel.com>
> wrote:
> > >
> > >>>> struct iommu_sva *iommu_sva_bind_device(struct device *dev,
> > >>>> struct mm_struct *mm) {
> > >>>> + struct iommu_mm_data *iommu_mm;
> > >>>> struct iommu_domain *domain;
> > >>>> struct iommu_sva *handle;
> > >>>> int ret;
> > >>>>
> > >>>> + mutex_lock(&iommu_sva_lock);
> > >>>> +
> > >>>> /* Allocate mm->pasid if necessary. */
> > >>>> - ret = iommu_sva_alloc_pasid(mm, dev);
> > >>>> - if (ret)
> > >>>> - return ERR_PTR(ret);
> > >>>> + iommu_mm = iommu_alloc_mm_data(mm, dev);
> > >>>> + if (IS_ERR(iommu_mm)) {
> > >>>> + ret = PTR_ERR(iommu_mm);
> > >>>> + goto out_unlock;
> > >>>> + }
> > >>>>
> > >>>> handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> > >>>> - if (!handle)
> > >>>> - return ERR_PTR(-ENOMEM);
> > >>>> -
> > >>>> - mutex_lock(&iommu_sva_lock);
> > >>>> - /* Search for an existing domain. */
> > >>>> - domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
> > >>>> - IOMMU_DOMAIN_SVA);
> > >>>> - if (IS_ERR(domain)) {
> > >>>> - ret = PTR_ERR(domain);
> > >>>> + if (!handle) {
> > >>>> + ret = -ENOMEM;
> > >>>> goto out_unlock;
> > >>>> }
> > >>>>
> > >>>> - if (domain) {
> > >>>> - domain->users++;
> > >>>> - goto out;
> > >>> Our multi bind test case broke since 6.8-rc1.
> > >>> The test case can use same domain & pasid, return different
> > >>> handle,
> > >>> 6.7 simply domain->users ++ and return.
> > >>>
> > >>>> + /* Search for an existing domain. */
> > >>>> + list_for_each_entry(domain, &mm->iommu_mm->sva_domains,
> > >>>> + next)
> > >>> {
> > >>>> + ret = iommu_attach_device_pasid(domain, dev,
> > >>>> + iommu_mm->pasid);
> > >>> Now iommu_attach_device_pasid return BUSY since the same pasid.
> > >>> And then iommu_sva_bind_device attach ret=-16
> > >> Sounds like the test case tries to bind a device to a same mm multiple
> times without unbinding the device and the expectation is that it can always
> return a valid handle to pass the test. Right?
> > > Yes
> > >
> > > The device can bind to the same mm multi-times and return different
> > > handle, Since the refcount, no need to unbind and bind sequently,
> > > The unbind can happen later with the handle.
> >
> > Is there any real use case to bind an mm to the pasid of a device
> > multiple times? If there are cases, is it better to handle this in the
> > uacce driver?
>
> Yes, it is required for multi-thread, the device can provide multi-queue to
> speed up.
>
> >
> > From iommu core's perspective, it doesn't make sense to attach the
> > same domain to the same device (or pasid) multiple times.
>
> But is it the refcount domain->user++ used for?
> Is there any reason not doing this.
The domain->user is a refcount of the devices (or iommu group) attached to the domain. IOMMU core needs to keep this refcount to ensure that a sva domain will be released when no device uses it.
Regards,
-Tina
>
> Thanks
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains
2024-02-21 7:41 ` Zhang, Tina
@ 2024-02-21 8:01 ` Zhangfei Gao
0 siblings, 0 replies; 24+ messages in thread
From: Zhangfei Gao @ 2024-02-21 8:01 UTC (permalink / raw)
To: Zhang, Tina
Cc: Baolu Lu, iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
David Woodhouse, Joerg Roedel, Will Deacon, Robin Murphy,
Jason Gunthorpe, Tian, Kevin, Nicolin Chen, Michael Shavit,
Vasant Hegde, Jason Gunthorpe, Jean-Philippe Brucker, Hao Fang
On Wed, 21 Feb 2024 at 15:41, Zhang, Tina <tina.zhang@intel.com> wrote:
>
> Hi,
>
> > -----Original Message-----
> > From: Zhangfei Gao <zhangfei.gao@linaro.org>
> > Sent: Wednesday, February 21, 2024 10:45 AM
> > To: Baolu Lu <baolu.lu@linux.intel.com>
> > Cc: Zhang, Tina <tina.zhang@intel.com>; iommu@lists.linux.dev; linux-
> > kernel@vger.kernel.org; David Woodhouse <dwmw2@infradead.org>; Joerg
> > Roedel <joro@8bytes.org>; Will Deacon <will@kernel.org>; Robin Murphy
> > <robin.murphy@arm.com>; Jason Gunthorpe <jgg@ziepe.ca>; Tian, Kevin
> > <kevin.tian@intel.com>; Nicolin Chen <nicolinc@nvidia.com>; Michael Shavit
> > <mshavit@google.com>; Vasant Hegde <vasant.hegde@amd.com>; Jason
> > Gunthorpe <jgg@nvidia.com>; Jean-Philippe Brucker <jean-
> > philippe@linaro.org>; Hao Fang <fanghao11@huawei.com>
> > Subject: Re: [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva
> > domains
> >
> > On Wed, 21 Feb 2024 at 10:06, Baolu Lu <baolu.lu@linux.intel.com> wrote:
> > >
> > > On 2024/2/21 9:28, Zhangfei Gao wrote:
> > > > On Wed, 21 Feb 2024 at 07:58, Zhang, Tina<tina.zhang@intel.com>
> > wrote:
> > > >
> > > >>>> struct iommu_sva *iommu_sva_bind_device(struct device *dev,
> > > >>>> struct mm_struct *mm) {
> > > >>>> + struct iommu_mm_data *iommu_mm;
> > > >>>> struct iommu_domain *domain;
> > > >>>> struct iommu_sva *handle;
> > > >>>> int ret;
> > > >>>>
> > > >>>> + mutex_lock(&iommu_sva_lock);
> > > >>>> +
> > > >>>> /* Allocate mm->pasid if necessary. */
> > > >>>> - ret = iommu_sva_alloc_pasid(mm, dev);
> > > >>>> - if (ret)
> > > >>>> - return ERR_PTR(ret);
> > > >>>> + iommu_mm = iommu_alloc_mm_data(mm, dev);
> > > >>>> + if (IS_ERR(iommu_mm)) {
> > > >>>> + ret = PTR_ERR(iommu_mm);
> > > >>>> + goto out_unlock;
> > > >>>> + }
> > > >>>>
> > > >>>> handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> > > >>>> - if (!handle)
> > > >>>> - return ERR_PTR(-ENOMEM);
> > > >>>> -
> > > >>>> - mutex_lock(&iommu_sva_lock);
> > > >>>> - /* Search for an existing domain. */
> > > >>>> - domain = iommu_get_domain_for_dev_pasid(dev, mm->pasid,
> > > >>>> - IOMMU_DOMAIN_SVA);
> > > >>>> - if (IS_ERR(domain)) {
> > > >>>> - ret = PTR_ERR(domain);
> > > >>>> + if (!handle) {
> > > >>>> + ret = -ENOMEM;
> > > >>>> goto out_unlock;
> > > >>>> }
> > > >>>>
> > > >>>> - if (domain) {
> > > >>>> - domain->users++;
> > > >>>> - goto out;
> > > >>> Our multi bind test case broke since 6.8-rc1.
> > > >>> The test case can use same domain & pasid, return different
> > > >>> handle,
> > > >>> 6.7 simply domain->users ++ and return.
> > > >>>
> > > >>>> + /* Search for an existing domain. */
> > > >>>> + list_for_each_entry(domain, &mm->iommu_mm->sva_domains,
> > > >>>> + next)
> > > >>> {
> > > >>>> + ret = iommu_attach_device_pasid(domain, dev,
> > > >>>> + iommu_mm->pasid);
> > > >>> Now iommu_attach_device_pasid return BUSY since the same pasid.
> > > >>> And then iommu_sva_bind_device attach ret=-16
> > > >> Sounds like the test case tries to bind a device to a same mm multiple
> > times without unbinding the device and the expectation is that it can always
> > return a valid handle to pass the test. Right?
> > > > Yes
> > > >
> > > > The device can bind to the same mm multi-times and return different
> > > > handle, Since the refcount, no need to unbind and bind sequently,
> > > > The unbind can happen later with the handle.
> > >
> > > Is there any real use case to bind an mm to the pasid of a device
> > > multiple times? If there are cases, is it better to handle this in the
> > > uacce driver?
> >
> > Yes, it is required for multi-thread, the device can provide multi-queue to
> > speed up.
> >
> > >
> > > From iommu core's perspective, it doesn't make sense to attach the
> > > same domain to the same device (or pasid) multiple times.
> >
> > But is it the refcount domain->user++ used for?
> > Is there any reason not doing this.
> The domain->user is a refcount of the devices (or iommu group) attached to the domain. IOMMU core needs to keep this refcount to ensure that a sva domain will be released when no device uses it.
I think the limitation of one user only attach one domain one time
does not make sense.
Just like one file can only be opened one time by a user, then
refcount is meanless.
Thanks
>
> Regards,
> -Tina
>
> >
> > Thanks
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v10 6/6] mm: Deprecate pasid field
2023-10-27 0:05 [PATCH v10 0/6] Share sva domains with all devices bound to a mm Tina Zhang
` (4 preceding siblings ...)
2023-10-27 0:05 ` [PATCH v10 5/6] iommu: Support mm PASID 1:n with sva domains Tina Zhang
@ 2023-10-27 0:05 ` Tina Zhang
2023-12-12 9:12 ` [PATCH v10 0/6] Share sva domains with all devices bound to a mm Joerg Roedel
6 siblings, 0 replies; 24+ messages in thread
From: Tina Zhang @ 2023-10-27 0:05 UTC (permalink / raw)
To: iommu, linux-kernel
Cc: David Woodhouse, Lu Baolu, Joerg Roedel, Will Deacon,
Robin Murphy, Jason Gunthorpe, Kevin Tian, Nicolin Chen,
Michael Shavit, Vasant Hegde, Tina Zhang, Jason Gunthorpe
Drop the pasid field, as all the information needed for sva domain
management has been moved to the newly added iommu_mm field.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
include/linux/mm_types.h | 1 -
mm/init-mm.c | 3 ---
2 files changed, 4 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 2dbf18e26c5a..5fb881b4758c 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -883,7 +883,6 @@ struct mm_struct {
struct work_struct async_put_work;
#ifdef CONFIG_IOMMU_MM_DATA
- u32 pasid;
struct iommu_mm_data *iommu_mm;
#endif
#ifdef CONFIG_KSM
diff --git a/mm/init-mm.c b/mm/init-mm.c
index c52dc2740a3d..24c809379274 100644
--- a/mm/init-mm.c
+++ b/mm/init-mm.c
@@ -44,9 +44,6 @@ struct mm_struct init_mm = {
#endif
.user_ns = &init_user_ns,
.cpu_bitmap = CPU_BITS_NONE,
-#ifdef CONFIG_IOMMU_MM_DATA
- .pasid = IOMMU_PASID_INVALID,
-#endif
INIT_MM_CONTEXT(init_mm)
};
--
2.39.3
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH v10 0/6] Share sva domains with all devices bound to a mm
2023-10-27 0:05 [PATCH v10 0/6] Share sva domains with all devices bound to a mm Tina Zhang
` (5 preceding siblings ...)
2023-10-27 0:05 ` [PATCH v10 6/6] mm: Deprecate pasid field Tina Zhang
@ 2023-12-12 9:12 ` Joerg Roedel
6 siblings, 0 replies; 24+ messages in thread
From: Joerg Roedel @ 2023-12-12 9:12 UTC (permalink / raw)
To: Tina Zhang
Cc: iommu, linux-kernel, David Woodhouse, Lu Baolu, Will Deacon,
Robin Murphy, Jason Gunthorpe, Kevin Tian, Nicolin Chen,
Michael Shavit, Vasant Hegde
On Fri, Oct 27, 2023 at 08:05:19AM +0800, Tina Zhang wrote:
> Jason Gunthorpe (1):
> iommu: Change kconfig around IOMMU_SVA
>
> Tina Zhang (5):
> iommu/vt-d: Remove mm->pasid in intel_sva_bind_mm()
> iommu: Add mm_get_enqcmd_pasid() helper function
> mm: Add structure to keep sva information
> iommu: Support mm PASID 1:n with sva domains
> mm: Deprecate pasid field
Applied, thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread