All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
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>,
	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: Mon, 21 Aug 2023 15:31:40 -0300	[thread overview]
Message-ID: <ZOOtjJLumarsBzwN@ziepe.ca> (raw)
In-Reply-To: <20230817234047.195194-1-baolu.lu@linux.intel.com>

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..

iommu_report_device_fault() and iommu_queue_iopf() should be put in
the same file.

iommu_queue_iopf() seems misnamed since it isn't queuing anything. It
is delivering the fault to the domain.

It is weird that iommu_sva_domain_alloc is not in the sva file

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.

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.

Jason

  parent reply	other threads:[~2023-08-21 18:31 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 ` Jason Gunthorpe [this message]
2023-08-23  1:24   ` [PATCH v3 00/11] iommu: Prepare to deliver page faults to user space 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=ZOOtjJLumarsBzwN@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe@linaro.org \
    --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.