iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: iommu@lists.linux-foundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	Joerg Roedel <joro@8bytes.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Alex Williamson <alex.williamson@redhat.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	Raj Ashok <ashok.raj@intel.com>,
	Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	Jonathan Cameron <jic23@kernel.org>
Subject: [PATCH v5 02/19] iommu: handle page response timeout
Date: Thu, 15 Aug 2019 13:13:08 -0700	[thread overview]
Message-ID: <1565900005-62508-3-git-send-email-jacob.jun.pan@linux.intel.com> (raw)
In-Reply-To: <1565900005-62508-1-git-send-email-jacob.jun.pan@linux.intel.com>

When IO page faults are reported outside IOMMU subsystem, the page
request handler may fail for various reasons. E.g. a guest received
page requests but did not have a chance to run for a long time. The
irresponsive behavior could hold off limited resources on the pending
device.
There can be hardware or credit based software solutions as suggested
in the PCI ATS Ch-4. To provide a basic safty net this patch
introduces a per device deferrable timer which monitors the longest
pending page fault that requires a response. Proper action such as
sending failure response code could be taken when timer expires but not
included in this patch. We need to consider the life cycle of page
groupd ID to prevent confusion with reused group ID by a device.
For now, a warning message provides clue of such failure.

Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
---
 drivers/iommu/iommu.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/iommu.h |  4 ++++
 2 files changed, 59 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 5b26499..8f2c7d5 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -909,6 +909,39 @@ int iommu_group_unregister_notifier(struct iommu_group *group,
 }
 EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier);
 
+static void iommu_dev_fault_timer_fn(struct timer_list *t)
+{
+	struct iommu_fault_param *fparam = from_timer(fparam, t, timer);
+	struct iommu_fault_event *evt;
+	struct iommu_fault_page_request *prm;
+
+	u64 now;
+
+	now = get_jiffies_64();
+
+	/* The goal is to ensure driver or guest page fault handler(via vfio)
+	 * send page response on time. Otherwise, limited queue resources
+	 * may be occupied by some irresponsive guests or drivers.
+	 * When per device pending fault list is not empty, we periodically checks
+	 * if any anticipated page response time has expired.
+	 *
+	 * TODO:
+	 * We could do the following if response time expires:
+	 * 1. send page response code FAILURE to all pending PRQ
+	 * 2. inform device driver or vfio
+	 * 3. drain in-flight page requests and responses for this device
+	 * 4. clear pending fault list such that driver can unregister fault
+	 *    handler(otherwise blocked when pending faults are present).
+	 */
+	list_for_each_entry(evt, &fparam->faults, list) {
+		prm = &evt->fault.prm;
+		if (time_after64(now, evt->expire))
+			pr_err("Page response time expired!, pasid %d gid %d exp %llu now %llu\n",
+				prm->pasid, prm->grpid, evt->expire, now);
+	}
+	mod_timer(t, now + prq_timeout);
+}
+
 /**
  * iommu_register_device_fault_handler() - Register a device fault handler
  * @dev: the device
@@ -956,6 +989,9 @@ int iommu_register_device_fault_handler(struct device *dev,
 	mutex_init(&param->fault_param->lock);
 	INIT_LIST_HEAD(&param->fault_param->faults);
 
+	if (prq_timeout)
+		timer_setup(&param->fault_param->timer, iommu_dev_fault_timer_fn,
+			TIMER_DEFERRABLE);
 done_unlock:
 	mutex_unlock(&param->lock);
 
@@ -1017,7 +1053,9 @@ 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 = NULL;
 	struct iommu_fault_param *fparam;
+	struct timer_list *tmr;
 	int ret = 0;
+	u64 exp;
 
 	if (!param || !evt)
 		return -EINVAL;
@@ -1038,7 +1076,17 @@ int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt)
 			ret = -ENOMEM;
 			goto done_unlock;
 		}
+		/* Keep track of response expiration time */
+		exp = get_jiffies_64() + prq_timeout;
+		evt_pending->expire = exp;
 		mutex_lock(&fparam->lock);
+		if (list_empty(&fparam->faults)) {
+			/* First pending event, start timer */
+			tmr = &dev->iommu_param->fault_param->timer;
+			WARN_ON(timer_pending(tmr));
+			mod_timer(tmr, exp);
+		}
+
 		list_add_tail(&evt_pending->list, &fparam->faults);
 		mutex_unlock(&fparam->lock);
 	}
@@ -1103,6 +1151,13 @@ int iommu_page_response(struct device *dev,
 		break;
 	}
 
+	/* stop response timer if no more pending request */
+	if (list_empty(&param->fault_param->faults) &&
+		timer_pending(&param->fault_param->timer)) {
+		pr_debug("no pending PRQ, stop timer\n");
+		del_timer(&param->fault_param->timer);
+	}
+
 done_unlock:
 	mutex_unlock(&param->fault_param->lock);
 	return ret;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index fdc355c..39d371b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -317,10 +317,12 @@ struct iommu_device {
  *
  * @fault: fault descriptor
  * @list: pending fault event list, used for tracking responses
+ * @expire: time limit in jiffies will wait for page response
  */
 struct iommu_fault_event {
 	struct iommu_fault fault;
 	struct list_head list;
+	u64 expire;
 };
 
 /**
@@ -329,11 +331,13 @@ struct iommu_fault_event {
  * @data: handler private data
  * @faults: holds the pending faults which needs response
  * @lock: protect pending faults list
+ * @timer: track page request pending time limit
  */
 struct iommu_fault_param {
 	iommu_dev_fault_handler_t handler;
 	void *data;
 	struct list_head faults;
+	struct timer_list timer;
 	struct mutex lock;
 };
 
-- 
2.7.4

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

  parent reply	other threads:[~2019-08-15 20:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 20:13 [PATCH v5 00/19] Shared virtual address IOMMU and VT-d support Jacob Pan
2019-08-15 20:13 ` [PATCH v5 01/19] iommu: Add a timeout parameter for PRQ response Jacob Pan
2019-08-15 20:13 ` Jacob Pan [this message]
2019-08-15 20:13 ` [PATCH v5 03/19] trace/iommu: Add sva trace events Jacob Pan
2019-08-15 20:13 ` [PATCH v5 04/19] iommu: Use device fault trace event Jacob Pan
2019-08-15 20:13 ` [PATCH v5 05/19] iommu: Introduce attach/detach_pasid_table API Jacob Pan
2019-08-15 20:13 ` [PATCH v5 06/19] iommu: Introduce cache_invalidate API Jacob Pan
2019-08-15 20:13 ` [PATCH v5 07/19] iommu: Add I/O ASID allocator Jacob Pan
2019-08-15 20:13 ` [PATCH v5 08/19] iommu/ioasid: Add custom allocators Jacob Pan
2019-08-15 20:13 ` [PATCH v5 09/19] iommu: Introduce guest PASID bind function Jacob Pan
2019-08-15 20:13 ` [PATCH v5 10/19] iommu/vt-d: Enlightened PASID allocation Jacob Pan
2019-08-15 20:13 ` [PATCH v5 11/19] iommu/vt-d: Add custom allocator for IOASID Jacob Pan
2019-08-15 20:13 ` [PATCH v5 12/19] iommu/vt-d: Replace Intel specific PASID allocator with IOASID Jacob Pan
2019-08-15 20:13 ` [PATCH v5 13/19] iommu/vt-d: Move domain helper to header Jacob Pan
2019-08-15 20:13 ` [PATCH v5 14/19] iommu/vt-d: Avoid duplicated code for PASID setup Jacob Pan
2019-08-15 20:13 ` [PATCH v5 15/19] iommu/vt-d: Add nested translation helper function Jacob Pan
2019-08-15 20:13 ` [PATCH v5 16/19] iommu/vt-d: Misc macro clean up for SVM Jacob Pan
2019-08-15 21:17   ` Andy Shevchenko
2019-08-15 22:50     ` Jacob Pan
2019-08-15 20:13 ` [PATCH v5 17/19] iommu/vt-d: Add bind guest PASID support Jacob Pan
2019-08-15 20:13 ` [PATCH v5 18/19] iommu/vt-d: Support flushing more translation cache types Jacob Pan
2019-08-15 20:13 ` [PATCH v5 19/19] iommu/vt-d: Add svm/sva invalidate function Jacob Pan
2019-08-26 17:12 ` [PATCH v5 00/19] Shared virtual address IOMMU and VT-d support 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=1565900005-62508-3-git-send-email-jacob.jun.pan@linux.intel.com \
    --to=jacob.jun.pan@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe.brucker@arm.com \
    --cc=jic23@kernel.org \
    --cc=joro@8bytes.org \
    --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).