From: Baolu Lu <baolu.lu@linux.intel.com>
To: Ethan Zhao <haifeng.zhao@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>, Jason Gunthorpe <jgg@nvidia.com>,
Christoph Hellwig <hch@infradead.org>,
Kevin Tian <kevin.tian@intel.com>,
Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
Dave Jiang <dave.jiang@intel.com>, Vinod Koul <vkoul@kernel.org>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org,
Jacob jun Pan <jacob.jun.pan@intel.com>
Subject: Re: [PATCH v9 10/11] iommu: Per-domain I/O page fault handling
Date: Tue, 28 Jun 2022 14:28:14 +0800 [thread overview]
Message-ID: <693a3604-d70b-e08c-2621-7f0cb9bdb6ca@linux.intel.com> (raw)
In-Reply-To: <faacb997-0c0a-04e1-903d-53857f463214@linux.intel.com>
Hi Ethan,
On 2022/6/27 21:03, Ethan Zhao wrote:
> Hi,
>
> 在 2022/6/21 22:43, Lu Baolu 写道:
>> Tweak the I/O page fault handling framework to route the page faults to
>> the domain and call the page fault handler retrieved from the domain.
>> This makes the I/O page fault handling framework possible to serve more
>> usage scenarios as long as they have an IOMMU domain and install a page
>> fault handler in it. Some unused functions are also removed to avoid
>> dead code.
>>
>> The iommu_get_domain_for_dev_pasid() which retrieves attached domain
>> for a {device, PASID} pair is used. It will be used by the page fault
>> handling framework which knows {device, PASID} reported from the iommu
>> driver. We have a guarantee that the SVA domain doesn't go away during
>> IOPF handling, because unbind() waits for pending faults with
>> iopf_queue_flush_dev() before freeing the domain. Hence, there's no need
>> to synchronize life cycle of the iommu domains between the unbind() and
>> the interrupt threads.
>>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>> ---
>> drivers/iommu/io-pgfault.c | 64 +++++---------------------------------
>> 1 file changed, 7 insertions(+), 57 deletions(-)
>>
>> diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
>> index aee9e033012f..4f24ec703479 100644
>> --- a/drivers/iommu/io-pgfault.c
>> +++ b/drivers/iommu/io-pgfault.c
>> @@ -69,69 +69,18 @@ static int iopf_complete_group(struct device *dev,
>> struct iopf_fault *iopf,
>> return iommu_page_response(dev, &resp);
>> }
>> -static enum iommu_page_response_code
>> -iopf_handle_single(struct iopf_fault *iopf)
>> -{
>> - vm_fault_t ret;
>> - struct mm_struct *mm;
>> - struct vm_area_struct *vma;
>> - unsigned int access_flags = 0;
>> - unsigned int fault_flags = FAULT_FLAG_REMOTE;
>> - struct iommu_fault_page_request *prm = &iopf->fault.prm;
>> - enum iommu_page_response_code status = IOMMU_PAGE_RESP_INVALID;
>> -
>> - if (!(prm->flags & IOMMU_FAULT_PAGE_REQUEST_PASID_VALID))
>> - return status;
>> -
>> - mm = iommu_sva_find(prm->pasid);
>> - if (IS_ERR_OR_NULL(mm))
>> - return status;
>> -
>> - mmap_read_lock(mm);
>> -
>> - vma = find_extend_vma(mm, prm->addr);
>> - if (!vma)
>> - /* Unmapped area */
>> - goto out_put_mm;
>> -
>> - if (prm->perm & IOMMU_FAULT_PERM_READ)
>> - access_flags |= VM_READ;
>> -
>> - if (prm->perm & IOMMU_FAULT_PERM_WRITE) {
>> - access_flags |= VM_WRITE;
>> - fault_flags |= FAULT_FLAG_WRITE;
>> - }
>> -
>> - if (prm->perm & IOMMU_FAULT_PERM_EXEC) {
>> - access_flags |= VM_EXEC;
>> - fault_flags |= FAULT_FLAG_INSTRUCTION;
>> - }
>> -
>> - if (!(prm->perm & IOMMU_FAULT_PERM_PRIV))
>> - fault_flags |= FAULT_FLAG_USER;
>> -
>> - if (access_flags & ~vma->vm_flags)
>> - /* Access fault */
>> - goto out_put_mm;
>> -
>> - ret = handle_mm_fault(vma, prm->addr, fault_flags, NULL);
>> - status = ret & VM_FAULT_ERROR ? IOMMU_PAGE_RESP_INVALID :
>> - IOMMU_PAGE_RESP_SUCCESS;
>> -
>> -out_put_mm:
>> - mmap_read_unlock(mm);
>> - mmput(mm);
>> -
>> - return status;
>> -}
>> -
>
> Once the iopf_handle_single() is removed, the name of
> iopf_handle_group() looks a little weired
>
> and confused, does this group mean the iommu group (domain) ? while I
> take some minutes to
No. This is not the iommu group. It's page request group defined by the
PCI SIG spec. Multiple page requests could be put in a group with a
same group id. All page requests in a group could be responded to device
in one shot.
Best regards,
baolu
>
> look into the code, oh, means a batch / list / queue of iopfs , and
> iopf_handle_group() becomes a
>
> generic iopf_handler() .
>
> Doe it make sense to revise the names of iopf_handle_group(),
> iopf_complete_group, iopf_group in
>
> this patch set ?
>
>
> Thanks,
>
> Ethan
>
>> static void iopf_handle_group(struct work_struct *work)
>> {
>> struct iopf_group *group;
>> + struct iommu_domain *domain;
>> struct iopf_fault *iopf, *next;
>> enum iommu_page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
>> group = container_of(work, struct iopf_group, work);
>> + domain = iommu_get_domain_for_dev_pasid(group->dev,
>> + group->last_fault.fault.prm.pasid);
>> + if (!domain || !domain->iopf_handler)
>> + status = IOMMU_PAGE_RESP_INVALID;
>> list_for_each_entry_safe(iopf, next, &group->faults, list) {
>> /*
>> @@ -139,7 +88,8 @@ static void iopf_handle_group(struct work_struct
>> *work)
>> * faults in the group if there is an error.
>> */
>> if (status == IOMMU_PAGE_RESP_SUCCESS)
>> - status = iopf_handle_single(iopf);
>> + status = domain->iopf_handler(&iopf->fault,
>> + domain->fault_data);
>> if (!(iopf->fault.prm.flags &
>> IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE))
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Ethan Zhao <haifeng.zhao@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>, Jason Gunthorpe <jgg@nvidia.com>,
Christoph Hellwig <hch@infradead.org>,
Kevin Tian <kevin.tian@intel.com>,
Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
Dave Jiang <dave.jiang@intel.com>, Vinod Koul <vkoul@kernel.org>
Cc: baolu.lu@linux.intel.com, Eric Auger <eric.auger@redhat.com>,
Liu Yi L <yi.l.liu@intel.com>,
Jacob jun Pan <jacob.jun.pan@intel.com>,
iommu@lists.linux-foundation.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org,
Jean-Philippe Brucker <jean-philippe@linaro.org>
Subject: Re: [PATCH v9 10/11] iommu: Per-domain I/O page fault handling
Date: Tue, 28 Jun 2022 14:28:14 +0800 [thread overview]
Message-ID: <693a3604-d70b-e08c-2621-7f0cb9bdb6ca@linux.intel.com> (raw)
Message-ID: <20220628062814.dy89sFf0-xlXDtyfNt4bbC2xfShs6v37plIBCfv1Y4s@z> (raw)
In-Reply-To: <faacb997-0c0a-04e1-903d-53857f463214@linux.intel.com>
Hi Ethan,
On 2022/6/27 21:03, Ethan Zhao wrote:
> Hi,
>
> 在 2022/6/21 22:43, Lu Baolu 写道:
>> Tweak the I/O page fault handling framework to route the page faults to
>> the domain and call the page fault handler retrieved from the domain.
>> This makes the I/O page fault handling framework possible to serve more
>> usage scenarios as long as they have an IOMMU domain and install a page
>> fault handler in it. Some unused functions are also removed to avoid
>> dead code.
>>
>> The iommu_get_domain_for_dev_pasid() which retrieves attached domain
>> for a {device, PASID} pair is used. It will be used by the page fault
>> handling framework which knows {device, PASID} reported from the iommu
>> driver. We have a guarantee that the SVA domain doesn't go away during
>> IOPF handling, because unbind() waits for pending faults with
>> iopf_queue_flush_dev() before freeing the domain. Hence, there's no need
>> to synchronize life cycle of the iommu domains between the unbind() and
>> the interrupt threads.
>>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
>> ---
>> drivers/iommu/io-pgfault.c | 64 +++++---------------------------------
>> 1 file changed, 7 insertions(+), 57 deletions(-)
>>
>> diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
>> index aee9e033012f..4f24ec703479 100644
>> --- a/drivers/iommu/io-pgfault.c
>> +++ b/drivers/iommu/io-pgfault.c
>> @@ -69,69 +69,18 @@ static int iopf_complete_group(struct device *dev,
>> struct iopf_fault *iopf,
>> return iommu_page_response(dev, &resp);
>> }
>> -static enum iommu_page_response_code
>> -iopf_handle_single(struct iopf_fault *iopf)
>> -{
>> - vm_fault_t ret;
>> - struct mm_struct *mm;
>> - struct vm_area_struct *vma;
>> - unsigned int access_flags = 0;
>> - unsigned int fault_flags = FAULT_FLAG_REMOTE;
>> - struct iommu_fault_page_request *prm = &iopf->fault.prm;
>> - enum iommu_page_response_code status = IOMMU_PAGE_RESP_INVALID;
>> -
>> - if (!(prm->flags & IOMMU_FAULT_PAGE_REQUEST_PASID_VALID))
>> - return status;
>> -
>> - mm = iommu_sva_find(prm->pasid);
>> - if (IS_ERR_OR_NULL(mm))
>> - return status;
>> -
>> - mmap_read_lock(mm);
>> -
>> - vma = find_extend_vma(mm, prm->addr);
>> - if (!vma)
>> - /* Unmapped area */
>> - goto out_put_mm;
>> -
>> - if (prm->perm & IOMMU_FAULT_PERM_READ)
>> - access_flags |= VM_READ;
>> -
>> - if (prm->perm & IOMMU_FAULT_PERM_WRITE) {
>> - access_flags |= VM_WRITE;
>> - fault_flags |= FAULT_FLAG_WRITE;
>> - }
>> -
>> - if (prm->perm & IOMMU_FAULT_PERM_EXEC) {
>> - access_flags |= VM_EXEC;
>> - fault_flags |= FAULT_FLAG_INSTRUCTION;
>> - }
>> -
>> - if (!(prm->perm & IOMMU_FAULT_PERM_PRIV))
>> - fault_flags |= FAULT_FLAG_USER;
>> -
>> - if (access_flags & ~vma->vm_flags)
>> - /* Access fault */
>> - goto out_put_mm;
>> -
>> - ret = handle_mm_fault(vma, prm->addr, fault_flags, NULL);
>> - status = ret & VM_FAULT_ERROR ? IOMMU_PAGE_RESP_INVALID :
>> - IOMMU_PAGE_RESP_SUCCESS;
>> -
>> -out_put_mm:
>> - mmap_read_unlock(mm);
>> - mmput(mm);
>> -
>> - return status;
>> -}
>> -
>
> Once the iopf_handle_single() is removed, the name of
> iopf_handle_group() looks a little weired
>
> and confused, does this group mean the iommu group (domain) ? while I
> take some minutes to
No. This is not the iommu group. It's page request group defined by the
PCI SIG spec. Multiple page requests could be put in a group with a
same group id. All page requests in a group could be responded to device
in one shot.
Best regards,
baolu
>
> look into the code, oh, means a batch / list / queue of iopfs , and
> iopf_handle_group() becomes a
>
> generic iopf_handler() .
>
> Doe it make sense to revise the names of iopf_handle_group(),
> iopf_complete_group, iopf_group in
>
> this patch set ?
>
>
> Thanks,
>
> Ethan
>
>> static void iopf_handle_group(struct work_struct *work)
>> {
>> struct iopf_group *group;
>> + struct iommu_domain *domain;
>> struct iopf_fault *iopf, *next;
>> enum iommu_page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
>> group = container_of(work, struct iopf_group, work);
>> + domain = iommu_get_domain_for_dev_pasid(group->dev,
>> + group->last_fault.fault.prm.pasid);
>> + if (!domain || !domain->iopf_handler)
>> + status = IOMMU_PAGE_RESP_INVALID;
>> list_for_each_entry_safe(iopf, next, &group->faults, list) {
>> /*
>> @@ -139,7 +88,8 @@ static void iopf_handle_group(struct work_struct
>> *work)
>> * faults in the group if there is an error.
>> */
>> if (status == IOMMU_PAGE_RESP_SUCCESS)
>> - status = iopf_handle_single(iopf);
>> + status = domain->iopf_handler(&iopf->fault,
>> + domain->fault_data);
>> if (!(iopf->fault.prm.flags &
>> IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE))
>
next prev parent reply other threads:[~2022-06-28 6:28 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 14:43 [PATCH v9 00/11] iommu: SVA and IOPF refactoring Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-21 14:43 ` [PATCH v9 01/11] iommu: Add max_pasids field in struct iommu_device Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-27 8:05 ` Tian, Kevin
2022-06-27 8:05 ` Tian, Kevin
2022-06-21 14:43 ` [PATCH v9 02/11] iommu: Add max_pasids field in struct dev_iommu Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-27 8:06 ` Tian, Kevin
2022-06-27 8:06 ` Tian, Kevin
2022-06-21 14:43 ` [PATCH v9 03/11] iommu: Remove SVM_FLAG_SUPERVISOR_MODE support Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-21 14:43 ` [PATCH v9 04/11] iommu: Add sva iommu_domain support Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-27 8:29 ` Tian, Kevin
2022-06-27 8:29 ` Tian, Kevin
2022-06-28 5:41 ` Baolu Lu
2022-06-28 5:41 ` Baolu Lu
2022-06-28 8:50 ` Tian, Kevin
2022-06-28 8:50 ` Tian, Kevin
2022-06-28 11:33 ` Baolu Lu
2022-06-28 11:33 ` Baolu Lu
2022-06-29 1:54 ` Tian, Kevin
2022-06-29 1:54 ` Tian, Kevin
2022-06-29 4:44 ` Baolu Lu
2022-06-29 4:44 ` Baolu Lu
2022-06-28 11:41 ` Baolu Lu
2022-06-28 11:41 ` Baolu Lu
2022-06-21 14:43 ` [PATCH v9 05/11] iommu/vt-d: Add SVA domain support Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-27 8:32 ` Tian, Kevin
2022-06-27 8:32 ` Tian, Kevin
2022-06-21 14:43 ` [PATCH v9 06/11] arm-smmu-v3/sva: " Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-27 11:50 ` Zhangfei Gao
2022-06-27 11:50 ` Zhangfei Gao
2022-06-28 5:46 ` Baolu Lu
2022-06-28 5:46 ` Baolu Lu
2022-06-28 6:13 ` Baolu Lu
2022-06-28 6:13 ` Baolu Lu
2022-06-28 6:17 ` Zhu, Tony
2022-06-28 6:17 ` Zhu, Tony
2022-06-21 14:43 ` [PATCH v9 07/11] iommu/sva: Refactoring iommu_sva_bind/unbind_device() Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-27 10:14 ` Tian, Kevin
2022-06-27 10:14 ` Tian, Kevin
2022-06-28 5:53 ` Baolu Lu
2022-06-28 5:53 ` Baolu Lu
2022-06-28 8:52 ` Tian, Kevin
2022-06-28 8:52 ` Tian, Kevin
2022-06-21 14:43 ` [PATCH v9 08/11] iommu: Remove SVA related callbacks from iommu ops Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-21 14:43 ` [PATCH v9 09/11] iommu: Prepare IOMMU domain for IOPF Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-28 8:29 ` Tian, Kevin
2022-06-28 8:29 ` Tian, Kevin
2022-06-28 10:49 ` Baolu Lu
2022-06-28 10:49 ` Baolu Lu
2022-06-21 14:43 ` [PATCH v9 10/11] iommu: Per-domain I/O page fault handling Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-27 13:03 ` Ethan Zhao
2022-06-27 13:03 ` Ethan Zhao
2022-06-28 6:28 ` Baolu Lu [this message]
2022-06-28 6:28 ` Baolu Lu
2022-06-28 9:10 ` Ethan Zhao
2022-06-28 9:10 ` Ethan Zhao
2022-06-28 11:53 ` Baolu Lu
2022-06-28 11:53 ` Baolu Lu
2022-06-28 14:20 ` Jean-Philippe Brucker
2022-06-28 14:20 ` Jean-Philippe Brucker
2022-06-29 0:24 ` Baolu Lu
2022-06-29 0:24 ` Baolu Lu
2022-06-29 6:15 ` Ethan Zhao
2022-06-29 6:15 ` Ethan Zhao
2022-06-28 8:39 ` Tian, Kevin
2022-06-28 8:39 ` Tian, Kevin
2022-06-28 9:44 ` Jean-Philippe Brucker
2022-06-28 9:44 ` Jean-Philippe Brucker
2022-06-28 10:02 ` Tian, Kevin
2022-06-28 10:02 ` Tian, Kevin
2022-06-28 12:18 ` Baolu Lu
2022-06-28 12:18 ` Baolu Lu
2022-06-28 11:02 ` Baolu Lu
2022-06-28 11:02 ` Baolu Lu
2022-06-21 14:43 ` [PATCH v9 11/11] iommu: Rename iommu-sva-lib.{c,h} Lu Baolu
2022-06-21 14:43 ` Lu Baolu
2022-06-28 8:40 ` Tian, Kevin
2022-06-28 8:40 ` Tian, Kevin
2022-06-26 1:15 ` [PATCH v9 00/11] iommu: SVA and IOPF refactoring Baolu Lu
2022-06-26 1:15 ` 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=693a3604-d70b-e08c-2621-7f0cb9bdb6ca@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=dave.jiang@intel.com \
--cc=haifeng.zhao@linux.intel.com \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=iommu@lists.linux.dev \
--cc=jacob.jun.pan@intel.com \
--cc=jean-philippe@linaro.com \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--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=will@kernel.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 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.