All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: joro@8bytes.org, will@kernel.org, lorenzo.pieralisi@arm.com,
	robh+dt@kernel.org, guohanjun@huawei.com, sudeep.holla@arm.com,
	rjw@rjwysocki.net, lenb@kernel.org, robin.murphy@arm.com,
	eric.auger@redhat.com, iommu@lists.linux-foundation.org,
	devicetree@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-accelerators@lists.ozlabs.org, baolu.lu@linux.intel.com,
	vdumpa@nvidia.com, zhangfei.gao@linaro.org,
	shameerali.kolothum.thodi@huawei.com, vivek.gautam@arm.com
Subject: Re: [PATCH v9 06/10] iommu: Add a page fault handler
Date: Wed, 20 Jan 2021 18:43:55 +0100	[thread overview]
Message-ID: <YAhr28EbUNNJt08t@myrica> (raw)
In-Reply-To: <20210119133819.000015f6@Huawei.com>

On Tue, Jan 19, 2021 at 01:38:19PM +0000, Jonathan Cameron wrote:
> On Fri, 8 Jan 2021 15:52:14 +0100
> Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> 
> > Some systems allow devices to handle I/O Page Faults in the core mm. For
> > example systems implementing the PCIe PRI extension or Arm SMMU stall
> > model. Infrastructure for reporting these recoverable page faults was
> > added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device
> > fault report API"). Add a page fault handler for host SVA.
> > 
> > IOMMU driver can now instantiate several fault workqueues and link them
> > to IOPF-capable devices. Drivers can choose between a single global
> > workqueue, one per IOMMU device, one per low-level fault queue, one per
> > domain, etc.
> > 
> > When it receives a fault event, supposedly in an IRQ handler, the IOMMU
> 
> Why "supposedly"? Do you mean "most commonly" 
> 
> > driver reports the fault using iommu_report_device_fault(), which calls
> > the registered handler. The page fault handler then calls the mm fault
> > handler, and reports either success or failure with iommu_page_response().
> > When the handler succeeds, the IOMMU retries the access.
> 
> For PRI that description is perhaps a bit missleading.  IIRC the IOMMU
> will only retry when it gets a new ATS query.
> 
> > 
> > The iopf_param pointer could be embedded into iommu_fault_param. But
> > putting iopf_param into the iommu_param structure allows us not to care
> > about ordering between calls to iopf_queue_add_device() and
> > iommu_register_device_fault_handler().
> > 
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> 
> One really minor inconsistency inline that made me look twice..
> With or without that tided up FWIW.
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Thanks! I'll fix these up and resend
Jean


WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: devicetree@vger.kernel.org, linux-acpi@vger.kernel.org,
	robin.murphy@arm.com, guohanjun@huawei.com, rjw@rjwysocki.net,
	iommu@lists.linux-foundation.org, robh+dt@kernel.org,
	linux-accelerators@lists.ozlabs.org, sudeep.holla@arm.com,
	vivek.gautam@arm.com, zhangfei.gao@linaro.org, will@kernel.org,
	linux-arm-kernel@lists.infradead.org, lenb@kernel.org
Subject: Re: [PATCH v9 06/10] iommu: Add a page fault handler
Date: Wed, 20 Jan 2021 18:43:55 +0100	[thread overview]
Message-ID: <YAhr28EbUNNJt08t@myrica> (raw)
In-Reply-To: <20210119133819.000015f6@Huawei.com>

On Tue, Jan 19, 2021 at 01:38:19PM +0000, Jonathan Cameron wrote:
> On Fri, 8 Jan 2021 15:52:14 +0100
> Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> 
> > Some systems allow devices to handle I/O Page Faults in the core mm. For
> > example systems implementing the PCIe PRI extension or Arm SMMU stall
> > model. Infrastructure for reporting these recoverable page faults was
> > added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device
> > fault report API"). Add a page fault handler for host SVA.
> > 
> > IOMMU driver can now instantiate several fault workqueues and link them
> > to IOPF-capable devices. Drivers can choose between a single global
> > workqueue, one per IOMMU device, one per low-level fault queue, one per
> > domain, etc.
> > 
> > When it receives a fault event, supposedly in an IRQ handler, the IOMMU
> 
> Why "supposedly"? Do you mean "most commonly" 
> 
> > driver reports the fault using iommu_report_device_fault(), which calls
> > the registered handler. The page fault handler then calls the mm fault
> > handler, and reports either success or failure with iommu_page_response().
> > When the handler succeeds, the IOMMU retries the access.
> 
> For PRI that description is perhaps a bit missleading.  IIRC the IOMMU
> will only retry when it gets a new ATS query.
> 
> > 
> > The iopf_param pointer could be embedded into iommu_fault_param. But
> > putting iopf_param into the iommu_param structure allows us not to care
> > about ordering between calls to iopf_queue_add_device() and
> > iommu_register_device_fault_handler().
> > 
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> 
> One really minor inconsistency inline that made me look twice..
> With or without that tided up FWIW.
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Thanks! I'll fix these up and resend
Jean

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: devicetree@vger.kernel.org, lorenzo.pieralisi@arm.com,
	linux-acpi@vger.kernel.org, robin.murphy@arm.com,
	joro@8bytes.org, guohanjun@huawei.com, rjw@rjwysocki.net,
	shameerali.kolothum.thodi@huawei.com, eric.auger@redhat.com,
	iommu@lists.linux-foundation.org, robh+dt@kernel.org,
	linux-accelerators@lists.ozlabs.org, sudeep.holla@arm.com,
	vivek.gautam@arm.com, zhangfei.gao@linaro.org,
	baolu.lu@linux.intel.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org, lenb@kernel.org
Subject: Re: [PATCH v9 06/10] iommu: Add a page fault handler
Date: Wed, 20 Jan 2021 18:43:55 +0100	[thread overview]
Message-ID: <YAhr28EbUNNJt08t@myrica> (raw)
In-Reply-To: <20210119133819.000015f6@Huawei.com>

On Tue, Jan 19, 2021 at 01:38:19PM +0000, Jonathan Cameron wrote:
> On Fri, 8 Jan 2021 15:52:14 +0100
> Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> 
> > Some systems allow devices to handle I/O Page Faults in the core mm. For
> > example systems implementing the PCIe PRI extension or Arm SMMU stall
> > model. Infrastructure for reporting these recoverable page faults was
> > added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device
> > fault report API"). Add a page fault handler for host SVA.
> > 
> > IOMMU driver can now instantiate several fault workqueues and link them
> > to IOPF-capable devices. Drivers can choose between a single global
> > workqueue, one per IOMMU device, one per low-level fault queue, one per
> > domain, etc.
> > 
> > When it receives a fault event, supposedly in an IRQ handler, the IOMMU
> 
> Why "supposedly"? Do you mean "most commonly" 
> 
> > driver reports the fault using iommu_report_device_fault(), which calls
> > the registered handler. The page fault handler then calls the mm fault
> > handler, and reports either success or failure with iommu_page_response().
> > When the handler succeeds, the IOMMU retries the access.
> 
> For PRI that description is perhaps a bit missleading.  IIRC the IOMMU
> will only retry when it gets a new ATS query.
> 
> > 
> > The iopf_param pointer could be embedded into iommu_fault_param. But
> > putting iopf_param into the iommu_param structure allows us not to care
> > about ordering between calls to iopf_queue_add_device() and
> > iommu_register_device_fault_handler().
> > 
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> 
> One really minor inconsistency inline that made me look twice..
> With or without that tided up FWIW.
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Thanks! I'll fix these up and resend
Jean


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-20 17:47 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08 14:52 [PATCH v9 00/10] iommu: I/O page faults for SMMUv3 Jean-Philippe Brucker
2021-01-08 14:52 ` Jean-Philippe Brucker
2021-01-08 14:52 ` Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 01/10] iommu: Remove obsolete comment Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-19 11:11   ` Jonathan Cameron
2021-01-19 11:11     ` Jonathan Cameron
2021-01-19 11:11     ` Jonathan Cameron
2021-01-20 17:41     ` Jean-Philippe Brucker
2021-01-20 17:41       ` Jean-Philippe Brucker
2021-01-20 17:41       ` Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-19 11:22   ` Jonathan Cameron
2021-01-19 11:22     ` Jonathan Cameron
2021-01-19 11:22     ` Jonathan Cameron
2021-01-08 14:52 ` [PATCH v9 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-12  4:31   ` Lu Baolu
2021-01-12  4:31     ` Lu Baolu
2021-01-12  4:31     ` Lu Baolu
2021-01-12  9:16     ` Jean-Philippe Brucker
2021-01-12  9:16       ` Jean-Philippe Brucker
2021-01-12  9:16       ` Jean-Philippe Brucker
2021-01-13  2:49       ` Lu Baolu
2021-01-13  2:49         ` Lu Baolu
2021-01-13  2:49         ` Lu Baolu
2021-01-13  8:10         ` Tian, Kevin
2021-01-13  8:10           ` Tian, Kevin
2021-01-13  8:10           ` Tian, Kevin
2021-01-14 16:41           ` Jean-Philippe Brucker
2021-01-14 16:41             ` Jean-Philippe Brucker
2021-01-14 16:41             ` Jean-Philippe Brucker
2021-01-16  3:54             ` Lu Baolu
2021-01-16  3:54               ` Lu Baolu
2021-01-16  3:54               ` Lu Baolu
2021-01-18  6:54               ` Tian, Kevin
2021-01-18  6:54                 ` Tian, Kevin
2021-01-18  6:54                 ` Tian, Kevin
2021-01-19 10:16                 ` Jean-Philippe Brucker
2021-01-19 10:16                   ` Jean-Philippe Brucker
2021-01-19 10:16                   ` Jean-Philippe Brucker
2021-01-20  1:57                   ` Lu Baolu
2021-01-20  1:57                     ` Lu Baolu
2021-01-20  1:57                     ` Lu Baolu
2021-01-08 14:52 ` [PATCH v9 04/10] iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-11  3:29   ` Zhangfei Gao
2021-01-11  3:29     ` Zhangfei Gao
2021-01-11  3:29     ` Zhangfei Gao
2021-01-19 12:27   ` Jonathan Cameron
2021-01-19 12:27     ` Jonathan Cameron
2021-01-19 12:27     ` Jonathan Cameron
2021-01-20 17:42     ` Jean-Philippe Brucker
2021-01-20 17:42       ` Jean-Philippe Brucker
2021-01-20 17:42       ` Jean-Philippe Brucker
2021-01-20 20:47   ` Dave Jiang
2021-01-20 20:47     ` Dave Jiang
2021-01-20 20:47     ` Dave Jiang
2021-01-22 11:53     ` Zhou Wang
2021-01-22 11:53       ` Zhou Wang
2021-01-22 11:53       ` Zhou Wang
2021-01-22 15:43       ` Dave Jiang
2021-01-22 15:43         ` Dave Jiang
2021-01-22 15:43         ` Dave Jiang
2021-01-08 14:52 ` [PATCH v9 06/10] iommu: Add a page fault handler Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-19 13:38   ` Jonathan Cameron
2021-01-19 13:38     ` Jonathan Cameron
2021-01-19 13:38     ` Jonathan Cameron
2021-01-20 17:43     ` Jean-Philippe Brucker [this message]
2021-01-20 17:43       ` Jean-Philippe Brucker
2021-01-20 17:43       ` Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-19 13:51   ` Jonathan Cameron
2021-01-19 13:51     ` Jonathan Cameron
2021-01-19 13:51     ` Jonathan Cameron
2021-01-08 14:52 ` [PATCH v9 08/10] dt-bindings: document stall property for IOMMU masters Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 09/10] ACPI/IORT: Enable stall support for platform devices Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 10/10] iommu/arm-smmu-v3: Add " Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-08 14:52   ` Jean-Philippe Brucker
2021-01-19 17:28   ` Robin Murphy
2021-01-19 17:28     ` Robin Murphy
2021-01-19 17:28     ` Robin Murphy
2021-01-20 17:55     ` Jean-Philippe Brucker
2021-01-20 17:55       ` Jean-Philippe Brucker
2021-01-20 17:55       ` Jean-Philippe Brucker
2021-01-11  3:26 ` [PATCH v9 00/10] iommu: I/O page faults for SMMUv3 Zhangfei Gao
2021-01-11  3:26   ` Zhangfei Gao
2021-01-11  3:26   ` Zhangfei Gao

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=YAhr28EbUNNJt08t@myrica \
    --to=jean-philippe@linaro.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=eric.auger@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=lenb@kernel.org \
    --cc=linux-accelerators@lists.ozlabs.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=sudeep.holla@arm.com \
    --cc=vdumpa@nvidia.com \
    --cc=vivek.gautam@arm.com \
    --cc=will@kernel.org \
    --cc=zhangfei.gao@linaro.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.