Message ID | 20231018050640.24936-1-tina.zhang@intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4570655vqb; Tue, 17 Oct 2023 22:07:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE7s957LVC42IuS+mov+SWW9LrOC/ekJNF9/iI7y1xfmXleWLNziKbd+ous+cqu9IswDY0Q X-Received: by 2002:a17:90b:1812:b0:27c:fbf8:6c43 with SMTP id lw18-20020a17090b181200b0027cfbf86c43mr4523070pjb.1.1697605631564; Tue, 17 Oct 2023 22:07:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697605631; cv=none; d=google.com; s=arc-20160816; b=jAsH6+/wukzzYgkBctUhga/3la+hb/2VLVB8xLXVHbitpPAsSCsH1U3NqMOTBgDTIi jmAIosX2Vp2zSztosp2K810TX7cvSlCBv9MgH+O4zls8ABZSrIXMZ1aCtF394WZF2ceZ VOvCZa9x4K7oxXbdo7hmdUeq5K3LF+XeNSuwJkaxXAYkq3X4Ikk380YAHXwzMwBhvg2T QM1dRGt4CsjskOjJ9zJsKjRUU/O4In6TuWVfwb/PdYJbCBd75LpctcF/3SdAo+9lHxXr 7IseRwUb3S+hi+BCPwvr5wLwqjoHcZ78hyGZFMCTP7Kxzf61I2UnN9Yik+XenWNGG47M 4BIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=9ThFmNb53fImqmguLOZbTLdsQaiFtU4XhllXOaRJNcM=; fh=EuzH5lq/5R7ZpwjN9F0o8LZll1NVcXCrMgVes9t75ng=; b=sW3igyvz5e+XrqG4+xmbkRtpu4UIu8DJ6FMuZUebmOXfnYPktTigiKxZL16wX8g6TL jvqikqvpAx5UjZIt3B6p+WB0wcu1K2uoAU1kPhIgcrX9QF+Wg41uOPk1RZmRLUlAUP6s elgTaX+XPL36nMV447MLtmxFUhBVglyq6PNjfnllmH9EzWFrwcAvFqhC+4u4T9q1Isip 3rRJ3cRVafB6T66ir3fe0vMf6z/WB8apJ0z3Rr1StmI3+zAcR9yuGOYQI9j4RA3Ddsxp xBJJ/EANMKRMy5JFu3KxEuNTzRLaWE5Q14p7jRgxe5VmB+GRr1juGXT7AqSiqkts+l06 EUjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=T1JfhL00; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id ot14-20020a17090b3b4e00b00278eb61c0ebsi792585pjb.118.2023.10.17.22.07.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 22:07:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=T1JfhL00; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id D244A80FA866; Tue, 17 Oct 2023 22:07:10 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229529AbjJRFHE (ORCPT <rfc822;zwp10758@gmail.com> + 23 others); Wed, 18 Oct 2023 01:07:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbjJRFHD (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 18 Oct 2023 01:07:03 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5948FEA for <linux-kernel@vger.kernel.org>; Tue, 17 Oct 2023 22:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697605621; x=1729141621; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=1DhaoZRu99Prl8MkDJbYmg+5hgrE3uIsCY5cwtlP/jw=; b=T1JfhL00vOpIm7ZrDuUK68fE/3s+0TxlVlDAssmEVsYGsKwIpqFkRkix e93lw5z/JbNYGGQHDCzYmI2mm01rQ1tfyQQq9FzB4WqTxaRTD21y4p/BE LVne7XXFiMW96Jic6Va95RZIww7KS/l3w+5zt8IN0kyVj+3VII1SD/pcr EUKEI+Kbjjp32yiOOU5xsHuD4k8COztOn9H6oMDa66+3tPqEdPNQDYvRT y0WGmX6Mi/lgKKpkhaiA27EAr6vhu9NxX6IT446t57zNzAJVxKl/kHusW qtiKI1nHxF7+67vN/jY5dDf+ISDlH/lLb3uJqU5nrCHnwVOAdzY3ZJlSY g==; X-IronPort-AV: E=McAfee;i="6600,9927,10866"; a="388802372" X-IronPort-AV: E=Sophos;i="6.03,234,1694761200"; d="scan'208";a="388802372" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 22:07:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10866"; a="822288635" X-IronPort-AV: E=Sophos;i="6.03,234,1694761200"; d="scan'208";a="822288635" Received: from sqa-gate.sh.intel.com (HELO spr-2s5.tsp.org) ([10.239.48.212]) by fmsmga008.fm.intel.com with ESMTP; 17 Oct 2023 22:06:57 -0700 From: Tina Zhang <tina.zhang@intel.com> To: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Cc: 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>, Kevin Tian <kevin.tian@intel.com>, Nicolin Chen <nicolinc@nvidia.com>, Michael Shavit <mshavit@google.com>, Vasant Hegde <vasant.hegde@amd.com>, Tina Zhang <tina.zhang@intel.com> Subject: [PATCH v9 0/5] Share sva domains with all devices bound to a mm Date: Wed, 18 Oct 2023 13:06:35 +0800 Message-Id: <20231018050640.24936-1-tina.zhang@intel.com> X-Mailer: git-send-email 2.39.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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 (snail.vger.email [0.0.0.0]); Tue, 17 Oct 2023 22:07:10 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779961660517636355 X-GMAIL-MSGID: 1780068522809681682 |
Series |
Share sva domains with all devices bound to a mm
|
|
Message
Zhang, Tina
Oct. 18, 2023, 5:06 a.m. UTC
This series is to share sva(shared virtual addressing) domains with all devices bound to one mm. Problem ------- In the current iommu core code, sva domain is allocated per IOMMU group, when device driver is binding a process address space to a device (which is handled in iommu_sva_bind_device()). If one than more device is bound to the same process address space, there must be more than one sva domain instance, with each device having one. In other words, the sva domain doesn't share between those devices bound to the same process address space, and that leads to two problems: 1) device driver has to duplicate sva domains with enqcmd, as those sva domains have the same PASID and are relevant to one virtual address space. This makes the sva domain handling complex in device drivers. 2) IOMMU driver cannot get sufficient info of the IOMMUs that have devices behind them bound to the same virtual address space, when handling mmu_notifier_ops callbacks. As a result, IOMMU IOTLB invalidation is performed per device instead of per IOMMU, and that may lead to superfluous IOTLB invalidation issue, especially in a virtualization environment where all devices may be behind one virtual IOMMU. Solution -------- This patch-set tries to fix those two problems by allowing sharing sva domains with all devices bound to a mm. To achieve this, a new structure pointer is introduced to mm to replace the old PASID field, which can keep the info of PASID as well as the corresponding shared sva domains. Besides, function iommu_sva_bind_device() is updated to ensure a new sva domain can only be allocated when the old ones cannot work for the IOMMU. With these changes, a device driver can expect one sva domain could work for per PASID instance(e.g., enqcmd PASID instance), and therefore may get rid of handling sva domain duplication. Besides, IOMMU driver (e.g., intel vt-d driver) can get sufficient info (e.g., the info of the IOMMUs having their devices bound to one virtual address space) when handling mmu_notifier_ops callbacks, to remove the redundant IOTLB invalidations. Arguably there shouldn't be more than one sva_domain with the same PASID, and in any sane configuration there should be only 1 type of IOMMU driver that needs only 1 SVA domain. However, in reality, IOMMUs on one platform may not be identical to each other. Thus, attaching a sva domain that has been successfully bound to device A behind a IOMMU A, to device B behind IOMMU B may get failed due to the difference between IOMMU A and IOMMU B. In this case, a new sva domain with the same PASID needs to be allocated to work with IOMMU B. That's why we need a list to keep sva domains of one PASID. For the platform where IOMMUs are compatible to each other, there should be one sva domain in the list. v8: - CC more people - CC iommu@lists.linux.dev mailing list. When sending version 7, some issue happened in my CC list and that caused version 7 wasn't sent to iommu@lists.linux.dev. - Rebase to v6.6-rc6 and make a few format changes. v7: https://lore.kernel.org/lkml/20231012030112.82270-1-tina.zhang@intel.com/ - Add mm_pasid_init() back and do zeroing mm->iommu_mm pointer in mm_pasid_init() to avoid the use-after-free/double-free problem. - Update the commit message of patch "iommu: Add mm_get_enqcmd_pasid() helper function". v6: https://lore.kernel.org/linux-iommu/20231011065132.102676-1-tina.zhang@intel.com/ - Rename iommu_sva_alloc_pasid() to iommu_alloc_mm_data(). - Hold the iommu_sva_lock before invoking iommu_alloc_mm_data(). - Remove "iommu: Introduce mm_get_pasid() helper function" patch, because SMMUv3 decides to use mm_get_enqcmd_pasid() instead and other users are using iommu_sva_get_pasid() to get the pasid value. Besides, the iommu core accesses iommu_mm_data in the critical section protected by iommu_sva_lock. So no need to add another helper to retrieve PASID atomically. v5: https://lore.kernel.org/linux-iommu/20230925023813.575016-1-tina.zhang@intel.com/ - Order patch "iommu/vt-d: Remove mm->pasid in intel_sva_bind_mm()" first in this series. - Update commit message of patch "iommu: Introduce mm_get_pasid() helper function" - Use smp_store_release() & READ_ONCE() in storing and loading mm's pasid value. v4: https://lore.kernel.org/linux-iommu/20230912125936.722348-1-tina.zhang@intel.com/ - Rebase to v6.6-rc1. v3: https://lore.kernel.org/linux-iommu/20230905000930.24515-1-tina.zhang@intel.com/ - Add a comment describing domain->next. - Expand explanation of why PASID isn't released in iommu_sva_unbind_device(). - Add a patch to remove mm->pasid in intel_sva_bind_mm() v2: https://lore.kernel.org/linux-iommu/20230827084401.819852-1-tina.zhang@intel.com/ - Add mm_get_enqcmd_pasid(). - Update commit message. v1: https://lore.kernel.org/linux-iommu/20230808074944.7825-1-tina.zhang@intel.com/ RFC: https://lore.kernel.org/linux-iommu/20230707013441.365583-1-tina.zhang@intel.com/ 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 arch/x86/kernel/traps.c | 2 +- .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 14 +-- drivers/iommu/intel/svm.c | 14 +-- drivers/iommu/iommu-sva.c | 94 +++++++++++-------- include/linux/iommu.h | 38 +++++++- include/linux/mm_types.h | 3 +- mm/init-mm.c | 3 - 7 files changed, 108 insertions(+), 60 deletions(-)
Comments
On Wed, Oct 18, 2023 at 01:06:35PM +0800, Tina Zhang wrote: > 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 I don't know where Joerg has gone, he hasn't been able to answer three emails about this series in the last week. I'll take it through the iommufd tree so we can have an orderly next cycle for the three driver series already posted. If it reaches Joerg's tree before Sunday I'll drop it. We should have a discussion about process at LPC. Regards, Jason
Hi Tina, On Wed, Oct 18, 2023 at 01:06:35PM +0800, Tina Zhang wrote: > 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 Thanks for doing this, it all looks reasonable to me. But there is one thing missing which needs to be done before we can move forward with this. There was a discussion about the Kconfig symbol naming used in mm_struct. Please see the discussion here: https://lore.kernel.org/all/CAHk-=wgUiAtiszwseM1p2fCJ+sC4XWQ+YN4TanFhUgvUqjr9Xw@mail.gmail.com/ Please update this patch-set to solve this and I will take the series. Regards, Joerg
On Thu, Oct 26, 2023 at 09:24:40AM +0200, Joerg Roedel wrote: > Hi Tina, > > On Wed, Oct 18, 2023 at 01:06:35PM +0800, Tina Zhang wrote: > > 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 > > Thanks for doing this, it all looks reasonable to me. But there is one > thing missing which needs to be done before we can move forward with > this. > > There was a discussion about the Kconfig symbol naming used in > mm_struct. Please see the discussion here: > > https://lore.kernel.org/all/CAHk-=wgUiAtiszwseM1p2fCJ+sC4XWQ+YN4TanFhUgvUqjr9Xw@mail.gmail.com/ > > Please update this patch-set to solve this and I will take the series. Lets call it CONFIG_IOMMU_MM_DATA then. It is still pretty nonsensical but it speaks to what it does after this series Thanks, Jason
On Thu, Oct 26, 2023 at 09:20:16AM -0300, Jason Gunthorpe wrote: > On Thu, Oct 26, 2023 at 09:24:40AM +0200, Joerg Roedel wrote: > > Hi Tina, > > > > On Wed, Oct 18, 2023 at 01:06:35PM +0800, Tina Zhang wrote: > > > 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 > > > > Thanks for doing this, it all looks reasonable to me. But there is one > > thing missing which needs to be done before we can move forward with > > this. > > > > There was a discussion about the Kconfig symbol naming used in > > mm_struct. Please see the discussion here: > > > > https://lore.kernel.org/all/CAHk-=wgUiAtiszwseM1p2fCJ+sC4XWQ+YN4TanFhUgvUqjr9Xw@mail.gmail.com/ > > > > Please update this patch-set to solve this and I will take the series. > > Lets call it CONFIG_IOMMU_MM_DATA then. It is still pretty nonsensical > but it speaks to what it does after this series This is what I came up with: From ca97b6cb94eadc4066d762aa4c54e7ba9789f3f4 Mon Sep 17 00:00:00 2001 From: Jason Gunthorpe <jgg@nvidia.com> Date: Thu, 26 Oct 2023 10:43:12 -0300 Subject: [PATCH] iommu: Change kconfig around IOMMU_SVA 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 12d51495caec18..35b9fd559bb697 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 66bfabae881491..afd9c2dc228bdf 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 c876f1d36a81a7..2b62dbb3396add 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 5cc869db1b79fc..0f9c3f6ae8d32d 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -160,6 +160,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 8fb1b41b4d1580..0d2e01404c3e50 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -1324,7 +1324,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 36c5b43999e608..330f3cd8d5ad97 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 77f01ac385f7a5..3ac8e8556c3d93 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 3b6d20dfb9a85e..d28f0d4582dcc1 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 264a2df5ecf5b9..fee4a15e444b74 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 cfd367822cdd2e..c52dc2740a3de2 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)
Hi Jason and Joerg, Thanks for this commit. Version 10 of this patch-set has been submitted and this patch is added. Regards, -Tina > -----Original Message----- > From: Jason Gunthorpe <jgg@ziepe.ca> > Sent: Thursday, October 26, 2023 9:51 PM > To: Joerg Roedel <joro@8bytes.org> > Cc: Zhang, Tina <tina.zhang@intel.com>; 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 v9 0/5] Share sva domains with all devices bound to a mm > > On Thu, Oct 26, 2023 at 09:20:16AM -0300, Jason Gunthorpe wrote: > > On Thu, Oct 26, 2023 at 09:24:40AM +0200, Joerg Roedel wrote: > > > Hi Tina, > > > > > > On Wed, Oct 18, 2023 at 01:06:35PM +0800, Tina Zhang wrote: > > > > 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 > > > > > > Thanks for doing this, it all looks reasonable to me. But there is > > > one thing missing which needs to be done before we can move forward > > > with this. > > > > > > There was a discussion about the Kconfig symbol naming used in > > > mm_struct. Please see the discussion here: > > > > > > > > > https://lore.kernel.org/all/CAHk-=wgUiAtiszwseM1p2fCJ+sC4XWQ+YN4TanF > > > hUgvUqjr9Xw@mail.gmail.com/ > > > > > > Please update this patch-set to solve this and I will take the series. > > > > Lets call it CONFIG_IOMMU_MM_DATA then. It is still pretty nonsensical > > but it speaks to what it does after this series > > This is what I came up with: > > From ca97b6cb94eadc4066d762aa4c54e7ba9789f3f4 Mon Sep 17 00:00:00 > 2001 > From: Jason Gunthorpe <jgg@nvidia.com> > Date: Thu, 26 Oct 2023 10:43:12 -0300 > Subject: [PATCH] iommu: Change kconfig around IOMMU_SVA > > 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 > 12d51495caec18..35b9fd559bb697 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 > 66bfabae881491..afd9c2dc228bdf 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 > c876f1d36a81a7..2b62dbb3396add 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 > 5cc869db1b79fc..0f9c3f6ae8d32d 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -160,6 +160,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 > 8fb1b41b4d1580..0d2e01404c3e50 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -1324,7 +1324,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 > 36c5b43999e608..330f3cd8d5ad97 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 > 77f01ac385f7a5..3ac8e8556c3d93 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 > 3b6d20dfb9a85e..d28f0d4582dcc1 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 264a2df5ecf5b9..fee4a15e444b74 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 > cfd367822cdd2e..c52dc2740a3de2 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.42.0