From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: 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>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Nicolin Chen <nicolinc@nvidia.com>, Yi Liu <yi.l.liu@intel.com>,
iommu@lists.linux.dev, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH 5/9] iommu: Make fault_param generic
Date: Tue, 11 Jul 2023 14:31:51 -0700 [thread overview]
Message-ID: <20230711143151.3191f23c@jacob-builder> (raw)
In-Reply-To: <20230711010642.19707-6-baolu.lu@linux.intel.com>
Hi BaoLu,
On Tue, 11 Jul 2023 09:06:38 +0800, Lu Baolu <baolu.lu@linux.intel.com>
wrote:
> The iommu faults, including recoverable faults (IO page faults) and
> unrecoverable faults (DMA faults), are generic to all devices. The
> iommu faults could possibly be triggered for every device.
>
> The fault_param pointer under struct dev_iommu is the per-device fault
> data. Therefore, the fault_param pointer should be allocated during
> iommu device probe and freed when the device is released.
>
> With this done, the individual iommu drivers that support iopf have no
> need to call iommu_[un]register_device_fault_handler() any more.
> This will make it easier for the iommu drivers to support iopf, and it
> will also make the fault_param allocation and free simpler.
>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> ---
> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 13 +------------
> drivers/iommu/intel/iommu.c | 18 ++++--------------
> drivers/iommu/iommu.c | 14 ++++++++++++++
> 3 files changed, 19 insertions(+), 26 deletions(-)
>
> 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
> a5a63b1c947e..fa8ab9d413f8 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 @@ -437,7 +437,6 @@
> bool arm_smmu_master_sva_enabled(struct arm_smmu_master *master)
> static int arm_smmu_master_sva_enable_iopf(struct arm_smmu_master
> *master) {
> - int ret;
> struct device *dev = master->dev;
>
> /*
> @@ -450,16 +449,7 @@ static int arm_smmu_master_sva_enable_iopf(struct
> arm_smmu_master *master) if (!master->iopf_enabled)
> return -EINVAL;
>
> - ret = iopf_queue_add_device(master->smmu->evtq.iopf, dev);
> - if (ret)
> - return ret;
> -
> - ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf,
> dev);
> - if (ret) {
> - iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
> - return ret;
> - }
> - return 0;
> + return iopf_queue_add_device(master->smmu->evtq.iopf, dev);
> }
>
> static void arm_smmu_master_sva_disable_iopf(struct arm_smmu_master
> *master) @@ -469,7 +459,6 @@ static void
> arm_smmu_master_sva_disable_iopf(struct arm_smmu_master *master) if
> (!master->iopf_enabled) return;
>
> - iommu_unregister_device_fault_handler(dev);
> iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
> }
>
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 5c8c5cdc36cf..22e43db20252 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -4594,23 +4594,14 @@ static int intel_iommu_enable_iopf(struct device
> *dev) if (ret)
> return ret;
>
> - ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf,
> dev);
> - if (ret)
> - goto iopf_remove_device;
> -
> ret = pci_enable_pri(pdev, PRQ_DEPTH);
> - if (ret)
> - goto iopf_unregister_handler;
> + if (ret) {
> + iopf_queue_remove_device(iommu->iopf_queue, dev);
> + return ret;
> + }
> info->pri_enabled = 1;
>
> return 0;
> -
> -iopf_unregister_handler:
> - iommu_unregister_device_fault_handler(dev);
> -iopf_remove_device:
> - iopf_queue_remove_device(iommu->iopf_queue, dev);
> -
> - return ret;
> }
>
> static int intel_iommu_disable_iopf(struct device *dev)
> @@ -4637,7 +4628,6 @@ static int intel_iommu_disable_iopf(struct device
> *dev)
> * fault handler and removing device from iopf queue should never
> * fail.
> */
> - WARN_ON(iommu_unregister_device_fault_handler(dev));
> WARN_ON(iopf_queue_remove_device(iommu->iopf_queue, dev));
>
> return 0;
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 65895b987e22..8d1f0935ea71 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -299,7 +299,15 @@ static int dev_iommu_get(struct device *dev)
> return -ENOMEM;
>
> mutex_init(¶m->lock);
> + param->fault_param = kzalloc(sizeof(*param->fault_param),
> GFP_KERNEL);
since fault_param is _always_ allocated/freed along with param, can we merge
into one allocation? i.e.
struct dev_iommu {
struct mutex lock;
- struct iommu_fault_param *fault_param;
+ struct iommu_fault_param fault_param;
> + if (!param->fault_param) {
> + kfree(param);
> + return -ENOMEM;
> + }
> + mutex_init(¶m->fault_param->lock);
> + INIT_LIST_HEAD(¶m->fault_param->faults);
> dev->iommu = param;
> +
> return 0;
> }
>
> @@ -312,6 +320,12 @@ static void dev_iommu_free(struct device *dev)
> fwnode_handle_put(param->fwspec->iommu_fwnode);
> kfree(param->fwspec);
> }
> + /*
> + * All pending faults should have been drained before
> + * device release.
> + */
> + WARN_ON_ONCE(!list_empty(¶m->fault_param->faults));
> + kfree(param->fault_param);
> kfree(param);
> }
>
Thanks,
Jacob
next prev parent reply other threads:[~2023-07-11 21:26 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 1:06 [PATCH 0/9] iommu: Prepare to deliver page faults to user space Lu Baolu
2023-07-11 1:06 ` [PATCH 1/9] iommu: Move iommu fault data to linux/iommu.h Lu Baolu
2023-07-11 6:05 ` Tian, Kevin
2023-07-12 2:07 ` Baolu Lu
2023-07-12 9:33 ` Jean-Philippe Brucker
2023-07-13 3:22 ` Tian, Kevin
2023-07-13 3:48 ` Baolu Lu
2023-07-11 1:06 ` [PATCH 2/9] iommu: Add device parameter to iopf handler Lu Baolu
2023-07-11 17:26 ` Jacob Pan
2023-07-12 2:16 ` Baolu Lu
2023-07-12 5:46 ` Jacob Pan
2023-07-11 1:06 ` [PATCH 3/9] iommu: Add common code to handle IO page faults Lu Baolu
2023-07-11 6:12 ` Tian, Kevin
2023-07-12 2:32 ` Baolu Lu
2023-07-12 9:45 ` Jean-Philippe Brucker
2023-07-13 4:02 ` Baolu Lu
2023-07-11 20:50 ` Jacob Pan
2023-07-12 2:37 ` Baolu Lu
2023-07-11 1:06 ` [PATCH 4/9] iommu: Change the return value of dev_iommu_get() Lu Baolu
2023-07-11 21:05 ` Jacob Pan
2023-07-11 1:06 ` [PATCH 5/9] iommu: Make fault_param generic Lu Baolu
2023-07-11 6:14 ` Tian, Kevin
2023-07-12 2:43 ` Baolu Lu
2023-07-11 21:31 ` Jacob Pan [this message]
2023-07-12 3:02 ` Baolu Lu
2023-07-11 1:06 ` [PATCH 6/9] iommu: Remove iommu_[un]register_device_fault_handler() Lu Baolu
2023-07-11 1:06 ` [PATCH 7/9] iommu: Add helper to set iopf handler for domain Lu Baolu
2023-07-11 1:06 ` [PATCH 8/9] iommu: Add iommu page fault cookie helpers Lu Baolu
2023-07-11 1:06 ` [PATCH 9/9] iommu: Use fault cookie to store iopf_param Lu Baolu
2023-07-11 6:26 ` Tian, Kevin
2023-07-12 3:09 ` Baolu Lu
2023-07-11 22:02 ` Jacob Pan
2023-07-12 3:13 ` Baolu Lu
2023-07-13 3:24 ` Tian, Kevin
2023-07-13 3:43 ` Baolu Lu
2023-07-13 8:01 ` Tian, Kevin
2023-07-14 2:49 ` Baolu Lu
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=20230711143151.3191f23c@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.