From: Baolu Lu <baolu.lu@linux.intel.com>
To: Will Deacon <will@kernel.org>
Cc: Joerg Roedel <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Kevin Tian <kevin.tian@intel.com>,
Dave Jiang <dave.jiang@intel.com>, Vinod Koul <vkoul@kernel.org>,
Fenghua Yu <fenghuay@nvidia.com>,
Zhangfei Gao <zhangfei.gao@linaro.org>,
Zhou Wang <wangzhou1@hisilicon.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
Jason Gunthorpe <jgg@nvidia.com>
Subject: Re: [PATCH v3 01/12] iommu/arm-smmu-v3: Put iopf enablement in the domain attach path
Date: Wed, 12 Mar 2025 11:10:34 +0800 [thread overview]
Message-ID: <b1625daf-b77a-4838-8fed-f5ee2233fd2a@linux.intel.com> (raw)
In-Reply-To: <20250311161337.GD5138@willie-the-truck>
On 3/12/25 00:13, Will Deacon wrote:
> On Fri, Feb 28, 2025 at 05:26:20PM +0800, Lu Baolu wrote:
>> From: Jason Gunthorpe <jgg@nvidia.com>
>>
>> SMMUv3 co-mingles FEAT_IOPF and FEAT_SVA behaviors so that fault reporting
>> doesn't work unless both are enabled. This is not correct and causes
>> problems for iommufd which does not enable FEAT_SVA for it's fault capable
>> domains.
>>
>> These APIs are both obsolete, update SMMUv3 to use the new method like AMD
>> implements.
>>
>> A driver should enable iopf support when a domain with an iopf_handler is
>> attached, and disable iopf support when the domain is removed.
>>
>> Move the fault support logic to sva domain allocation and to domain
>> attach, refusing to create or attach fault capable domains if the HW
>> doesn't support it.
>>
>> Move all the logic for controlling the iopf queue under
>> arm_smmu_attach_prepare(). Keep track of the number of domains on the
>> master (over all the SSIDs) that require iopf. When the first domain
>> requiring iopf is attached create the iopf queue, when the last domain is
>> detached destroy it.
>>
>> Turn FEAT_IOPF and FEAT_SVA into no ops.
>>
>> Remove the sva_lock, this is all protected by the group mutex.
>>
>> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>> ---
>> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 86 +-------------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 105 +++++++++++++-----
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 39 ++-----
>> 3 files changed, 91 insertions(+), 139 deletions(-)
>
> [...]
>
>> @@ -2748,6 +2750,54 @@ to_smmu_domain_devices(struct iommu_domain *domain)
>> return NULL;
>> }
>>
>> +static int arm_smmu_enable_iopf(struct arm_smmu_master *master,
>> + struct arm_smmu_master_domain *master_domain)
>> +{
>> + int ret;
>> +
>> + iommu_group_mutex_assert(master->dev);
>> +
>> + if (!IS_ENABLED(CONFIG_ARM_SMMU_V3_SVA))
>> + return -EOPNOTSUPP;
>> +
>> + /*
>> + * Drivers for devices supporting PRI or stall require iopf others have
>> + * device-specific fault handlers and don't need IOPF, so this is not a
>> + * failure.
>> + */
>> + if (!master->stall_enabled)
>> + return 0;
>> +
>> + /* We're not keeping track of SIDs in fault events */
>> + if (master->num_streams != 1)
>> + return -EOPNOTSUPP;
>> +
>> + if (master->iopf_refcount) {
>> + master->iopf_refcount++;
>> + master_domain->using_iopf = true;
>> + return 0;
>> + }
>> +
>> + ret = iopf_queue_add_device(master->smmu->evtq.iopf, master->dev);
>> + if (ret)
>> + return ret;
>> + master->iopf_refcount = 1;
>> + master_domain->using_iopf = true;
>> + return 0;
>> +}
>> +
>> +static void arm_smmu_disable_iopf(struct arm_smmu_master *master)
>> +{
>> + iommu_group_mutex_assert(master->dev);
>> +
>> + if (!IS_ENABLED(CONFIG_ARM_SMMU_V3_SVA))
>> + return;
>
> I think it would be a little cleaner to push the '->using_iopf' check
> in here rather than have the callers check it. Then the SVA check above
> makes more sense and I think the enable/disable paths are a bit more
> symmetric.
Yes, sure. I will address it like this,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 4aaf9b7bf862..a519854b3798 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2786,13 +2786,17 @@ static int arm_smmu_enable_iopf(struct
arm_smmu_master *master,
return 0;
}
-static void arm_smmu_disable_iopf(struct arm_smmu_master *master)
+static void arm_smmu_disable_iopf(struct arm_smmu_master *master,
+ struct arm_smmu_master_domain
*master_domain)
{
iommu_group_mutex_assert(master->dev);
if (!IS_ENABLED(CONFIG_ARM_SMMU_V3_SVA))
return;
+ if (!master_domain || !master_domain->using_iopf)
+ return;
+
master->iopf_refcount--;
if (master->iopf_refcount == 0)
iopf_queue_remove_device(master->smmu->evtq.iopf,
master->dev);
@@ -2823,11 +2827,8 @@ static void arm_smmu_remove_master_domain(struct
arm_smmu_master *master,
}
spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
- if (master_domain) {
- if (master_domain->using_iopf)
- arm_smmu_disable_iopf(master);
- kfree(master_domain);
- }
+ arm_smmu_disable_iopf(master, master_domain);
+ kfree(master_domain);
}
/*
@@ -2945,8 +2946,7 @@ int arm_smmu_attach_prepare(struct
arm_smmu_attach_state *state,
return 0;
err_iopf:
- if (master_domain && master_domain->using_iopf)
- arm_smmu_disable_iopf(master);
+ arm_smmu_disable_iopf(master);
err_free_master_domain:
kfree(master_domain);
return ret;
>
> With that:
>
> Acked-by: Will Deacon <will@kernel.org>
>
> Will
Thanks,
baolu
next prev parent reply other threads:[~2025-03-12 3:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-28 9:26 [PATCH v3 00/12] iommu: Remove IOMMU_DEV_FEAT_SVA/_IOPF Lu Baolu
2025-02-28 9:26 ` [PATCH v3 01/12] iommu/arm-smmu-v3: Put iopf enablement in the domain attach path Lu Baolu
2025-03-11 16:13 ` Will Deacon
2025-03-12 3:10 ` Baolu Lu [this message]
2025-03-17 15:49 ` Jason Gunthorpe
2025-02-28 9:26 ` [PATCH v3 02/12] iommu/vt-d: Check if SVA is supported when attaching the SVA domain Lu Baolu
2025-02-28 9:26 ` [PATCH v3 03/12] iommu: Remove IOMMU_DEV_FEAT_SVA Lu Baolu
2025-02-28 9:26 ` [PATCH v3 04/12] iommu/vt-d: Move scalable mode ATS enablement to probe path Lu Baolu
2025-03-04 8:15 ` Tian, Kevin
2025-03-04 8:25 ` Baolu Lu
2025-02-28 9:26 ` [PATCH v3 05/12] iommu/vt-d: Move PRI enablement in " Lu Baolu
2025-03-04 8:19 ` Tian, Kevin
2025-02-28 9:26 ` [PATCH v3 06/12] iommu/vt-d: Cleanup intel_context_flush_present() Lu Baolu
2025-02-28 9:26 ` [PATCH v3 07/12] iommu/vt-d: Put iopf enablement in domain attach path Lu Baolu
2025-02-28 9:26 ` [PATCH v3 08/12] iommufd/selftest: " Lu Baolu
2025-02-28 9:26 ` [PATCH v3 09/12] dmaengine: idxd: Remove unnecessary IOMMU_DEV_FEAT_IOPF Lu Baolu
2025-02-28 9:26 ` [PATCH v3 10/12] uacce: " Lu Baolu
2025-02-28 9:26 ` [PATCH v3 11/12] iommufd: " Lu Baolu
2025-02-28 9:26 ` [PATCH v3 12/12] iommu: Remove iommu_dev_enable/disable_feature() Lu Baolu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b1625daf-b77a-4838-8fed-f5ee2233fd2a@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=fenghuay@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=vkoul@kernel.org \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=zhangfei.gao@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox