From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
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>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Longfang Liu <liulongfang@huawei.com>,
Yan Zhao <yan.y.zhao@intel.com>,
iommu@lists.linux.dev, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 12/12] iommu: Use refcount for fault data access
Date: Wed, 13 Dec 2023 10:19:32 +0800 [thread overview]
Message-ID: <cfc8cc32-8c62-440d-946f-69cd855fedaf@linux.intel.com> (raw)
In-Reply-To: <20231212151809.GD3013885@ziepe.ca>
On 12/12/23 11:18 PM, Jason Gunthorpe wrote:
> On Tue, Dec 12, 2023 at 01:07:17PM +0800, Baolu Lu wrote:
>
>> Yes, agreed. The iopf_fault_param should be passed in together with the
>> iopf_group. The reference count should be released in the
>> iopf_free_group(). These two helps could look like below:
>>
>> int iommu_page_response(struct iopf_group *group,
>> struct iommu_page_response *msg)
>> {
>> bool needs_pasid;
>> int ret = -EINVAL;
>> struct iopf_fault *evt;
>> struct iommu_fault_page_request *prm;
>> struct device *dev = group->fault_param->dev;
>> const struct iommu_ops *ops = dev_iommu_ops(dev);
>> bool has_pasid = msg->flags & IOMMU_PAGE_RESP_PASID_VALID;
>> struct iommu_fault_param *fault_param = group->fault_param;
>>
>> if (!ops->page_response)
>> return -ENODEV;
>
> We should never get here if this is the case, prevent the device from
> being added in the first place
Yeah, could move it to iopf_queue_add_device(). WARN and return failure
there if the driver is not ready for page request handling.
>
>> /* Only send response if there is a fault report pending */
>> mutex_lock(&fault_param->lock);
>> if (list_empty(&fault_param->faults)) {
>> dev_warn_ratelimited(dev, "no pending PRQ, drop response\n");
>> goto done_unlock;
>> }
>> /*
>> * Check if we have a matching page request pending to respond,
>> * otherwise return -EINVAL
>> */
>> list_for_each_entry(evt, &fault_param->faults, list) {
>> prm = &evt->fault.prm;
>> if (prm->grpid != msg->grpid)
>> continue;
>>
>> /*
>> * If the PASID is required, the corresponding request is
>> * matched using the group ID, the PASID valid bit and the PASID
>> * value. Otherwise only the group ID matches request and
>> * response.
>> */
>> needs_pasid = prm->flags & IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID;
>> if (needs_pasid && (!has_pasid || msg->pasid != prm->pasid))
>> continue;
>>
>> if (!needs_pasid && has_pasid) {
>> /* No big deal, just clear it. */
>> msg->flags &= ~IOMMU_PAGE_RESP_PASID_VALID;
>> msg->pasid = 0;
>> }
>>
>> ret = ops->page_response(dev, evt, msg);
>> list_del(&evt->list);
>> kfree(evt);
>> break;
>> }
>>
>> done_unlock:
>> mutex_unlock(&fault_param->lock);
>
> I would have expected the group to free'd here? But regardless this
> looks like a good direction
Both work for me. We can decide it according to the needs of code later.
>
> Jason
Best regards,
baolu
next prev parent reply other threads:[~2023-12-13 2:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 6:42 [PATCH v8 00/12] iommu: Prepare to deliver page faults to user space Lu Baolu
2023-12-07 6:42 ` [PATCH v8 01/12] iommu: Move iommu fault data to linux/iommu.h Lu Baolu
2023-12-07 6:42 ` [PATCH v8 02/12] iommu/arm-smmu-v3: Remove unrecoverable faults reporting Lu Baolu
2023-12-07 6:42 ` [PATCH v8 03/12] iommu: Remove unrecoverable fault data Lu Baolu
2023-12-07 6:43 ` [PATCH v8 04/12] iommu: Cleanup iopf data structure definitions Lu Baolu
2023-12-07 6:43 ` [PATCH v8 05/12] iommu: Merge iopf_device_param into iommu_fault_param Lu Baolu
2023-12-07 6:43 ` [PATCH v8 06/12] iommu: Remove iommu_[un]register_device_fault_handler() Lu Baolu
2023-12-07 6:43 ` [PATCH v8 07/12] iommu: Merge iommu_fault_event and iopf_fault Lu Baolu
2023-12-07 6:43 ` [PATCH v8 08/12] iommu: Prepare for separating SVA and IOPF Lu Baolu
2023-12-07 6:43 ` [PATCH v8 09/12] iommu: Make iommu_queue_iopf() more generic Lu Baolu
2023-12-07 6:43 ` [PATCH v8 10/12] iommu: Separate SVA and IOPF Lu Baolu
2023-12-07 6:43 ` [PATCH v8 11/12] iommu: Refine locking for per-device fault data management Lu Baolu
2023-12-11 14:50 ` Jason Gunthorpe
2023-12-07 6:43 ` [PATCH v8 12/12] iommu: Use refcount for fault data access Lu Baolu
2023-12-11 15:12 ` Jason Gunthorpe
2023-12-12 3:44 ` Baolu Lu
2023-12-12 15:18 ` Jason Gunthorpe
2023-12-11 15:24 ` Jason Gunthorpe
2023-12-12 5:07 ` Baolu Lu
2023-12-12 15:18 ` Jason Gunthorpe
2023-12-13 2:19 ` Baolu Lu [this message]
2023-12-12 5:17 ` Baolu Lu
2023-12-12 15:14 ` Jason Gunthorpe
2023-12-13 2:14 ` Baolu Lu
2023-12-12 5:23 ` 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=cfc8cc32-8c62-440d-946f-69cd855fedaf@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.jun.pan@linux.intel.com \
--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=liulongfang@huawei.com \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=yan.y.zhao@intel.com \
--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.