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>,
iommu@lists.linux.dev, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 00/11] iommu: Prepare to deliver page faults to user space
Date: Wed, 23 Aug 2023 09:24:03 +0800 [thread overview]
Message-ID: <c0c89983-cba4-1cb0-1cb5-9aae217da318@linux.intel.com> (raw)
In-Reply-To: <ZOOtjJLumarsBzwN@ziepe.ca>
On 2023/8/22 2:31, Jason Gunthorpe wrote:
> On Fri, Aug 18, 2023 at 07:40:36AM +0800, Lu Baolu wrote:
>> When a user-managed page table is attached to an IOMMU, it is necessary
>> to deliver IO page faults to user space so that they can be handled
>> appropriately. One use case for this is nested translation, which is
>> currently being discussed in the mailing list.
>>
>> I have posted a RFC series [1] that describes the implementation of
>> delivering page faults to user space through IOMMUFD. This series has
>> received several comments on the IOMMU refactoring, which I am trying to
>> address in this series.
>
> Looking at this after all the patches are applied..
Thank you very much for reviewing my patches.
>
> iommu_report_device_fault() and iommu_queue_iopf() should be put in
> the same file.
Yes. I will move both into io-pgfault.c. After that, iommu_queue_iopf()
becomes static.
>
> iommu_queue_iopf() seems misnamed since it isn't queuing anything. It
> is delivering the fault to the domain.
Yeah, perhaps we can rename it to iommu_handle_iopf().
/**
* iommu_handle_iopf - IO Page Fault handler
* @fault: fault event
* @dev: struct device.
>
> It is weird that iommu_sva_domain_alloc is not in the sva file
Agreed. I will move it to iommu-sva.c.
> iopf_queue_work() wrappers a work queue, but it should trampoline
> through another function before invoking the driver's callback and not
> invoke it with a weird work_struct - decode the group and get back the
> domain. Every single handler will require the group and domain.
The work queue wrapper is duplicate. I will remove it and let the driver
to call queue_work() directly.
>
> Same for domain->iopf_handler, the domain should be an argument if we
> are invoking the function on a domain.
>
> Perhaps group->domain is a simple answer.
Yes. I will add domain in fault group and make it part of the parameters
of the callback.
Best regards,
baolu
prev parent reply other threads:[~2023-08-23 1:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 23:40 [PATCH v3 00/11] iommu: Prepare to deliver page faults to user space Lu Baolu
2023-08-17 23:40 ` [PATCH v3 01/11] iommu: Move iommu fault data to linux/iommu.h Lu Baolu
2023-08-17 23:40 ` [PATCH v3 02/11] iommu/arm-smmu-v3: Remove unrecoverable faults reporting Lu Baolu
2023-08-17 23:40 ` [PATCH v3 03/11] iommu: Remove unrecoverable fault data Lu Baolu
2023-08-17 23:40 ` [PATCH v3 04/11] iommu: Cleanup iopf data structure definitions Lu Baolu
2023-08-21 17:01 ` Jason Gunthorpe
2023-08-17 23:40 ` [PATCH v3 05/11] iommu: Merge iopf_device_param into iommu_fault_param Lu Baolu
2023-08-21 17:04 ` Jason Gunthorpe
2023-08-22 7:42 ` Baolu Lu
2023-08-17 23:40 ` [PATCH v3 06/11] iommu: Remove iommu_[un]register_device_fault_handler() Lu Baolu
2023-08-17 23:40 ` [PATCH v3 07/11] iommu: Prepare for separating SVA and IOPF Lu Baolu
2023-08-21 17:06 ` Jason Gunthorpe
2023-08-17 23:40 ` [PATCH v3 08/11] iommu: Move iopf_handler() to iommu-sva.c Lu Baolu
2023-08-17 23:40 ` [PATCH v3 09/11] iommu: Make iommu_queue_iopf() more generic Lu Baolu
2023-08-21 17:11 ` Jason Gunthorpe
2023-08-22 8:47 ` Baolu Lu
2023-08-17 23:40 ` [PATCH v3 10/11] iommu: Add debugging on domain lifetime for iopf Lu Baolu
2023-08-17 23:40 ` [PATCH v3 11/11] iommu: Separate SVA and IOPF in Makefile and Kconfig Lu Baolu
2023-08-21 18:31 ` [PATCH v3 00/11] iommu: Prepare to deliver page faults to user space Jason Gunthorpe
2023-08-23 1:24 ` Baolu Lu [this message]
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=c0c89983-cba4-1cb0-1cb5-9aae217da318@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.