From: Baolu Lu <baolu.lu@linux.intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Nicolin Chen <nicolinc@nvidia.com>
Cc: baolu.lu@linux.intel.com, "Liu, Yi L" <yi.l.liu@intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 12/12] iommu: Improve iopf_queue_flush_dev()
Date: Tue, 26 Sep 2023 09:49:10 +0800 [thread overview]
Message-ID: <b5d52bd4-7cb7-24b5-72d3-b5018306e352@linux.intel.com> (raw)
In-Reply-To: <BN9PR11MB5276E30109C63D06675042758CFCA@BN9PR11MB5276.namprd11.prod.outlook.com>
On 9/25/23 3:00 PM, Tian, Kevin wrote:
>> From: Lu Baolu <baolu.lu@linux.intel.com>
>> Sent: Thursday, September 14, 2023 4:57 PM
>> @@ -300,6 +299,7 @@ EXPORT_SYMBOL_GPL(iommu_page_response);
>> /**
>> * iopf_queue_flush_dev - Ensure that all queued faults have been
>> processed
>> * @dev: the endpoint whose faults need to be flushed.
>> + * @pasid: the PASID of the endpoint.
>> *
>> * The IOMMU driver calls this before releasing a PASID, to ensure that all
>> * pending faults for this PASID have been handled, and won't hit the
>> address
>
> the comment should be updated too.
Yes.
... pending faults for this PASID have been handled or dropped ...
>
>> @@ -309,17 +309,53 @@ EXPORT_SYMBOL_GPL(iommu_page_response);
>> *
>> * Return: 0 on success and <0 on error.
>> */
>> -int iopf_queue_flush_dev(struct device *dev)
>> +int iopf_queue_flush_dev(struct device *dev, ioasid_t pasid)
>
> iopf_queue_flush_dev_pasid()?
>
>> {
>> struct iommu_fault_param *iopf_param =
>> iopf_get_dev_fault_param(dev);
>> + const struct iommu_ops *ops = dev_iommu_ops(dev);
>> + struct iommu_page_response resp;
>> + struct iopf_fault *iopf, *next;
>> + int ret = 0;
>>
>> if (!iopf_param)
>> return -ENODEV;
>>
>> flush_workqueue(iopf_param->queue->wq);
>> +
>> + mutex_lock(&iopf_param->lock);
>> + list_for_each_entry_safe(iopf, next, &iopf_param->partial, list) {
>> + if (!(iopf->fault.prm.flags &
>> IOMMU_FAULT_PAGE_REQUEST_PASID_VALID) ||
>> + iopf->fault.prm.pasid != pasid)
>> + break;
>> +
>> + list_del(&iopf->list);
>> + kfree(iopf);
>> + }
>> +
>> + list_for_each_entry_safe(iopf, next, &iopf_param->faults, list) {
>> + if (!(iopf->fault.prm.flags &
>> IOMMU_FAULT_PAGE_REQUEST_PASID_VALID) ||
>> + iopf->fault.prm.pasid != pasid)
>> + continue;
>> +
>> + memset(&resp, 0, sizeof(struct iommu_page_response));
>> + resp.pasid = iopf->fault.prm.pasid;
>> + resp.grpid = iopf->fault.prm.grpid;
>> + resp.code = IOMMU_PAGE_RESP_INVALID;
>> +
>> + if (iopf->fault.prm.flags &
>> IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID)
>> + resp.flags = IOMMU_PAGE_RESP_PASID_VALID;
>> +
>> + ret = ops->page_response(dev, iopf, &resp);
>> + if (ret)
>> + break;
>> +
>> + list_del(&iopf->list);
>> + kfree(iopf);
>> + }
>> + mutex_unlock(&iopf_param->lock);
>> iopf_put_dev_fault_param(iopf_param);
>>
>> - return 0;
>> + return ret;
>> }
>
> Is it more accurate to call this function as iopf_queue_drop_dev_pasid()?
> The added logic essentially implies that the caller doesn't care about
> responses and all the in-fly states are either flushed (request) or
> abandoned (response).
>
> A normal flush() helper usually means just the flush action. If there is
> a need to wait for responses after flush then we could add a
> flush_dev_pasid_wait_timeout() later when there is a demand...
Fair enough.
As my understanding, "flush" means "handling the pending i/o page faults
immediately and wait until everything is done". Here what the caller
wants is "I have completed using this pasid, discard all the pending
requests by responding an INVALID result so that this PASID could be
reused".
If this holds, how about iopf_queue_discard_dev_pasid()? It matches the
existing iopf_queue_discard_partial().
Best regards,
baolu
next prev parent reply other threads:[~2023-09-26 1:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 8:56 [PATCH v5 00/12] iommu: Prepare to deliver page faults to user space Lu Baolu
2023-09-14 8:56 ` [PATCH v5 01/12] iommu: Move iommu fault data to linux/iommu.h Lu Baolu
2023-09-14 8:56 ` [PATCH v5 02/12] iommu/arm-smmu-v3: Remove unrecoverable faults reporting Lu Baolu
2023-09-14 8:56 ` [PATCH v5 03/12] iommu: Remove unrecoverable fault data Lu Baolu
2023-09-14 8:56 ` [PATCH v5 04/12] iommu: Cleanup iopf data structure definitions Lu Baolu
2023-09-14 8:56 ` [PATCH v5 05/12] iommu: Merge iopf_device_param into iommu_fault_param Lu Baolu
2023-09-14 8:56 ` [PATCH v5 06/12] iommu: Remove iommu_[un]register_device_fault_handler() Lu Baolu
2023-09-14 8:56 ` [PATCH v5 07/12] iommu: Merge iommu_fault_event and iopf_fault Lu Baolu
2023-09-25 6:47 ` Tian, Kevin
2023-09-14 8:56 ` [PATCH v5 08/12] iommu: Prepare for separating SVA and IOPF Lu Baolu
2023-09-14 8:56 ` [PATCH v5 09/12] iommu: Make iommu_queue_iopf() more generic Lu Baolu
2023-09-21 15:25 ` Liu, Jingqi
2023-09-21 23:34 ` Jason Gunthorpe
2023-09-22 2:44 ` Baolu Lu
2023-09-22 12:43 ` Jason Gunthorpe
2023-09-22 12:47 ` Baolu Lu
2023-09-25 6:49 ` Tian, Kevin
2023-09-14 8:56 ` [PATCH v5 10/12] iommu: Separate SVA and IOPF Lu Baolu
2023-09-25 6:49 ` Tian, Kevin
2023-09-14 8:56 ` [PATCH v5 11/12] iommu: Consolidate per-device fault data management Lu Baolu
2023-09-25 6:54 ` Tian, Kevin
2023-09-14 8:56 ` [PATCH v5 12/12] iommu: Improve iopf_queue_flush_dev() Lu Baolu
2023-09-25 7:00 ` Tian, Kevin
2023-09-26 1:49 ` Baolu Lu [this message]
2023-09-26 2:00 ` Tian, Kevin
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=b5d52bd4-7cb7-24b5-72d3-b5018306e352@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=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.