iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	Raj Ashok <ashok.raj@intel.com>,
	Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	iommu@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Andriy Shevchenko <andriy.shevchenko@linux.intel.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v4 04/22] iommu: Add recoverable fault reporting
Date: Tue, 18 Jun 2019 16:44:07 +0100	[thread overview]
Message-ID: <20190618164407.00005a96@huawei.com> (raw)
In-Reply-To: <1560087862-57608-5-git-send-email-jacob.jun.pan@linux.intel.com>

On Sun, 9 Jun 2019 06:44:04 -0700
Jacob Pan <jacob.jun.pan@linux.intel.com> wrote:

> From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> 
> Some IOMMU hardware features, for example PCI's PRI and Arm SMMU's Stall,
> enable recoverable I/O page faults. Allow IOMMU drivers to report PRI Page
> Requests and Stall events through the new fault reporting API. The
> consumer of the fault can be either an I/O page fault handler in the host,
> or a guest OS.
> 
> Once handled, the fault must be completed by sending a page response back
> to the IOMMU. Add an iommu_page_response() function to complete a page
> fault.
> 
> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
One totally trivial ordering of docs comment in here.  Otherwise good.

Jonathan
> ---
>  drivers/iommu/iommu.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>  include/linux/iommu.h | 51 ++++++++++++++++++++++++++++++++++
>  2 files changed, 127 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 7955184..13b301c 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -869,7 +869,14 @@ EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier);
>   * @data: private data passed as argument to the handler
>   *
>   * When an IOMMU fault event is received, this handler gets called with the
> - * fault event and data as argument.
> + * fault event and data as argument. The handler should return 0 on success. If
> + * the fault is recoverable (IOMMU_FAULT_PAGE_REQ), the handler should also
> + * complete the fault by calling iommu_page_response() with one of the following
> + * response code:
> + * - IOMMU_PAGE_RESP_SUCCESS: retry the translation
> + * - IOMMU_PAGE_RESP_INVALID: terminate the fault
> + * - IOMMU_PAGE_RESP_FAILURE: terminate the fault and stop reporting
> + *   page faults if possible.
>   *
>   * Return 0 if the fault handler was installed successfully, or an error.
>   */
> @@ -904,6 +911,8 @@ int iommu_register_device_fault_handler(struct device *dev,
>  	}
>  	param->fault_param->handler = handler;
>  	param->fault_param->data = data;
> +	mutex_init(&param->fault_param->lock);
> +	INIT_LIST_HEAD(&param->fault_param->faults);
>  
>  done_unlock:
>  	mutex_unlock(&param->lock);
> @@ -934,6 +943,12 @@ int iommu_unregister_device_fault_handler(struct device *dev)
>  	if (!param->fault_param)
>  		goto unlock;
>  
> +	/* we cannot unregister handler if there are pending faults */
> +	if (!list_empty(&param->fault_param->faults)) {
> +		ret = -EBUSY;
> +		goto unlock;
> +	}
> +
>  	kfree(param->fault_param);
>  	param->fault_param = NULL;
>  	put_device(dev);
> @@ -958,6 +973,7 @@ EXPORT_SYMBOL_GPL(iommu_unregister_device_fault_handler);
>  int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt)
>  {
>  	struct iommu_param *param = dev->iommu_param;
> +	struct iommu_fault_event *evt_pending;
>  	struct iommu_fault_param *fparam;
>  	int ret = 0;
>  
> @@ -972,6 +988,20 @@ int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt)
>  		ret = -EINVAL;
>  		goto done_unlock;
>  	}
> +
> +	if (evt->fault.type == IOMMU_FAULT_PAGE_REQ &&
> +	    (evt->fault.prm.flags & IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE)) {
> +		evt_pending = kmemdup(evt, sizeof(struct iommu_fault_event),
> +				      GFP_KERNEL);
> +		if (!evt_pending) {
> +			ret = -ENOMEM;
> +			goto done_unlock;
> +		}
> +		mutex_lock(&fparam->lock);
> +		list_add_tail(&evt_pending->list, &fparam->faults);
> +		mutex_unlock(&fparam->lock);
> +	}
> +
>  	ret = fparam->handler(evt, fparam->data);
>  done_unlock:
>  	mutex_unlock(&param->lock);
> @@ -1513,6 +1543,51 @@ int iommu_attach_device(struct iommu_domain *domain, struct device *dev)
>  }
>  EXPORT_SYMBOL_GPL(iommu_attach_device);
>  
> +int iommu_page_response(struct device *dev,
> +			struct page_response_msg *msg)
> +{
> +	struct iommu_param *param = dev->iommu_param;
> +	int ret = -EINVAL;
> +	struct iommu_fault_event *evt;
> +	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> +
> +	if (!domain || !domain->ops->page_response)
> +		return -ENODEV;
> +
> +	/*
> +	 * Device iommu_param should have been allocated when device is
> +	 * added to its iommu_group.
> +	 */
> +	if (!param || !param->fault_param)
> +		return -EINVAL;
> +
> +	/* Only send response if there is a fault report pending */
> +	mutex_lock(&param->fault_param->lock);
> +	if (list_empty(&param->fault_param->faults)) {
> +		pr_warn("no pending PRQ, drop response\n");
> +		goto done_unlock;
> +	}
> +	/*
> +	 * Check if we have a matching page request pending to respond,
> +	 * otherwise return -EINVAL
> +	 */
> +	list_for_each_entry(evt, &param->fault_param->faults, list) {
> +		if (evt->fault.prm.pasid == msg->pasid &&
> +		    evt->fault.prm.grpid == msg->grpid) {
> +			msg->iommu_data = evt->iommu_private;
> +			ret = domain->ops->page_response(dev, msg);
> +			list_del(&evt->list);
> +			kfree(evt);
> +			break;
> +		}
> +	}
> +
> +done_unlock:
> +	mutex_unlock(&param->fault_param->lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_page_response);
> +
>  static void __iommu_detach_device(struct iommu_domain *domain,
>  				  struct device *dev)
>  {
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index b87b74c..950347b 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -192,6 +192,42 @@ struct iommu_sva_ops {
>  #ifdef CONFIG_IOMMU_API
>  
>  /**
> + * enum page_response_code - Return status of fault handlers, telling the IOMMU
> + * driver how to proceed with the fault.
> + *
> + * @IOMMU_PAGE_RESP_SUCCESS: Fault has been handled and the page tables
> + *	populated, retry the access. This is "Success" in PCI PRI.
> + * @IOMMU_PAGE_RESP_FAILURE: General error. Drop all subsequent faults from
> + *	this device if possible. This is "Response Failure" in PCI PRI.
> + * @IOMMU_PAGE_RESP_INVALID: Could not handle this fault, don't retry the
> + *	access. This is "Invalid Request" in PCI PRI.
> + */
> +enum page_response_code {
> +	IOMMU_PAGE_RESP_SUCCESS = 0,
> +	IOMMU_PAGE_RESP_INVALID,
> +	IOMMU_PAGE_RESP_FAILURE,
> +};
> +
> +/**
> + * struct page_response_msg - Generic page response information based on PCI ATS
> + *                            and PASID spec
> + * @addr: servicing page address
> + * @pasid: contains process address space ID
> + * @pasid_present: the @pasid field is valid
> + * @resp_code: response code
> + * @grpid: page request group index
> + * @iommu_data: data private to the IOMMU
> + */
> +struct page_response_msg {
> +	u64 addr;
> +	u32 pasid;
> +	u32 pasid_present:1;
> +	enum page_response_code resp_code;
> +	u32 grpid;
> +	u64 iommu_data;
> +};
> +
> +/**
>   * struct iommu_ops - iommu ops and capabilities
>   * @capable: check capability
>   * @domain_alloc: allocate iommu domain
> @@ -227,6 +263,7 @@ struct iommu_sva_ops {
>   * @sva_bind: Bind process address space to device
>   * @sva_unbind: Unbind process address space from device
>   * @sva_get_pasid: Get PASID associated to a SVA handle
> + * @page_response: handle page request response
>   * @pgsize_bitmap: bitmap of all possible supported page sizes
>   */
>  struct iommu_ops {
> @@ -287,6 +324,8 @@ struct iommu_ops {
>  	void (*sva_unbind)(struct iommu_sva *handle);
>  	int (*sva_get_pasid)(struct iommu_sva *handle);
>  
> +	int (*page_response)(struct device *dev, struct page_response_msg *msg);
> +
>  	unsigned long pgsize_bitmap;
>  };
>  
> @@ -311,11 +350,13 @@ struct iommu_device {
>   * unrecoverable faults such as DMA or IRQ remapping faults.
>   *
>   * @fault: fault descriptor
> + * @list: pending fault event list, used for tracking responses

Ordering of docs vs structure is wrong.

>   * @iommu_private: used by the IOMMU driver for storing fault-specific
>   *                 data. Users should not modify this field before
>   *                 sending the fault response.
>   */
>  struct iommu_fault_event {
> +	struct list_head list;
>  	struct iommu_fault fault;
>  	u64 iommu_private;
>  };
> @@ -325,10 +366,14 @@ struct iommu_fault_event {
>   *
>   * @handler: Callback function to handle IOMMU faults at device level
>   * @data: handler private data
> + * @faults: holds the pending faults which needs response, e.g. page response.
> + * @lock: protect pending faults list
>   */
>  struct iommu_fault_param {
>  	iommu_dev_fault_handler_t handler;
>  	void *data;
> +	struct list_head faults;
> +	struct mutex lock;
>  };
>  
>  /**
> @@ -443,6 +488,7 @@ extern int iommu_unregister_device_fault_handler(struct device *dev);
>  extern int iommu_report_device_fault(struct device *dev,
>  				     struct iommu_fault_event *evt);
>  
> +extern int iommu_page_response(struct device *dev, struct page_response_msg *msg);
>  extern int iommu_group_id(struct iommu_group *group);
>  extern struct iommu_group *iommu_group_get_for_dev(struct device *dev);
>  extern struct iommu_domain *iommu_group_default_domain(struct iommu_group *);
> @@ -770,6 +816,11 @@ int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt)
>  	return -ENODEV;
>  }
>  
> +static inline int iommu_page_response(struct device *dev, struct page_response_msg *msg)
> +{
> +	return -ENODEV;
> +}
> +
>  static inline int iommu_group_id(struct iommu_group *group)
>  {
>  	return -ENODEV;


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

  reply	other threads:[~2019-06-18 15:44 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-09 13:44 [PATCH v4 00/22] Shared virtual address IOMMU and VT-d support Jacob Pan
2019-06-09 13:44 ` [PATCH v4 01/22] driver core: Add per device iommu param Jacob Pan
2019-06-09 13:44 ` [PATCH v4 02/22] iommu: Introduce device fault data Jacob Pan
2019-06-18 15:42   ` Jonathan Cameron
2019-06-09 13:44 ` [PATCH v4 03/22] iommu: Introduce device fault report API Jacob Pan
2019-06-18 15:41   ` Jonathan Cameron
2019-06-09 13:44 ` [PATCH v4 04/22] iommu: Add recoverable fault reporting Jacob Pan
2019-06-18 15:44   ` Jonathan Cameron [this message]
2019-06-09 13:44 ` [PATCH v4 05/22] iommu: Add a timeout parameter for PRQ response Jacob Pan
2019-06-09 13:44 ` [PATCH v4 06/22] trace/iommu: Add sva trace events Jacob Pan
2019-06-09 13:44 ` [PATCH v4 07/22] iommu: Use device fault trace event Jacob Pan
2019-06-09 13:44 ` [PATCH v4 08/22] iommu: Introduce attach/detach_pasid_table API Jacob Pan
2019-06-18 15:41   ` Jonathan Cameron
2019-06-24 15:06     ` Auger Eric
2019-06-24 15:23       ` Jean-Philippe Brucker
2019-06-09 13:44 ` [PATCH v4 09/22] iommu: Introduce cache_invalidate API Jacob Pan
2019-06-18 15:41   ` Jonathan Cameron
2019-06-09 13:44 ` [PATCH v4 10/22] iommu: Fix compile error without IOMMU_API Jacob Pan
2019-06-18 14:10   ` Jonathan Cameron
2019-06-24 22:28     ` Jacob Pan
2019-06-09 13:44 ` [PATCH v4 11/22] iommu: Introduce guest PASID bind function Jacob Pan
2019-06-18 15:36   ` Jean-Philippe Brucker
2019-06-24 22:24     ` Jacob Pan
2019-07-16 16:44   ` Auger Eric
2019-08-05 21:02     ` Jacob Pan
2019-08-05 23:13     ` Jacob Pan
2019-06-09 13:44 ` [PATCH v4 12/22] iommu: Add I/O ASID allocator Jacob Pan
2019-06-18 16:50   ` Jonathan Cameron
2019-06-25 18:55     ` Jacob Pan
2019-06-09 13:44 ` [PATCH v4 13/22] iommu/vt-d: Enlightened PASID allocation Jacob Pan
2019-07-16  9:29   ` Auger Eric
2019-08-13 16:57     ` Jacob Pan
2019-06-09 13:44 ` [PATCH v4 14/22] iommu/vt-d: Add custom allocator for IOASID Jacob Pan
2019-07-16  9:30   ` Auger Eric
2019-08-05 20:02     ` Jacob Pan
2019-06-09 13:44 ` [PATCH v4 15/22] iommu/vt-d: Replace Intel specific PASID allocator with IOASID Jacob Pan
2019-06-18 15:57   ` Jonathan Cameron
2019-06-24 21:36     ` Jacob Pan
2019-06-27  1:53   ` Lu Baolu
2019-06-27 15:40     ` Jacob Pan
2019-06-09 13:44 ` [PATCH v4 16/22] iommu/vt-d: Move domain helper to header Jacob Pan
2019-07-16  9:33   ` Auger Eric
2019-06-09 13:44 ` [PATCH v4 17/22] iommu/vt-d: Avoid duplicated code for PASID setup Jacob Pan
2019-06-18 16:03   ` Jonathan Cameron
2019-06-24 23:44     ` Jacob Pan
2019-07-16  9:52   ` Auger Eric
2019-06-09 13:44 ` [PATCH v4 18/22] iommu/vt-d: Add nested translation helper function Jacob Pan
2019-06-09 13:44 ` [PATCH v4 19/22] iommu/vt-d: Clean up for SVM device list Jacob Pan
2019-06-18 16:42   ` Jonathan Cameron
2019-06-24 23:59     ` Jacob Pan
2019-06-09 13:44 ` [PATCH v4 20/22] iommu/vt-d: Add bind guest PASID support Jacob Pan
2019-06-18 16:44   ` Jonathan Cameron
2019-06-24 22:41     ` Jacob Pan
2019-06-27  2:50   ` Lu Baolu
2019-06-27 20:22     ` Jacob Pan
2019-07-05  2:21       ` Lu Baolu
2019-08-14 17:20         ` Jacob Pan
2019-07-16 16:45   ` Auger Eric
2019-07-16 17:04     ` Raj, Ashok
2019-07-18  7:47       ` Auger Eric
2019-06-09 13:44 ` [PATCH v4 21/22] iommu/vt-d: Support flushing more translation cache types Jacob Pan
2019-07-18  8:35   ` Auger Eric
2019-08-14 20:17     ` Jacob Pan
2019-06-09 13:44 ` [PATCH v4 22/22] iommu/vt-d: Add svm/sva invalidate function Jacob Pan

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=20190618164407.00005a96@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=alex.williamson@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).