From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: YueHaibing <yuehaibing@huawei.com>,
Yanfei Xu <yanfei.xu@intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH 05/13] iommu/vt-d: Make prq draining code generic
Date: Wed, 9 Aug 2023 20:47:58 +0800 [thread overview]
Message-ID: <20230809124806.45516-6-baolu.lu@linux.intel.com> (raw)
In-Reply-To: <20230809124806.45516-1-baolu.lu@linux.intel.com>
Currently draining page requests and responses for a pasid is part of SVA
implementation. This is because the driver only supports attaching an SVA
domain to a device pasid. As we are about to support attaching other types
of domains to a device pasid, the prq draining code becomes generic.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Link: https://lore.kernel.org/r/20230802212427.1497170-6-jacob.jun.pan@linux.intel.com
---
drivers/iommu/intel/iommu.h | 2 ++
drivers/iommu/intel/iommu.c | 30 +++++++++++++++++++-----------
drivers/iommu/intel/svm.c | 17 ++---------------
3 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h
index 1c5e1d88862b..6d94a29f5d52 100644
--- a/drivers/iommu/intel/iommu.h
+++ b/drivers/iommu/intel/iommu.h
@@ -844,6 +844,7 @@ int intel_svm_page_response(struct device *dev, struct iommu_fault_event *evt,
struct iommu_page_response *msg);
struct iommu_domain *intel_svm_domain_alloc(void);
void intel_svm_remove_dev_pasid(struct device *dev, ioasid_t pasid);
+void intel_drain_pasid_prq(struct device *dev, u32 pasid);
struct intel_svm_dev {
struct list_head list;
@@ -862,6 +863,7 @@ struct intel_svm {
};
#else
static inline void intel_svm_check(struct intel_iommu *iommu) {}
+static inline void intel_drain_pasid_prq(struct device *dev, u32 pasid) {}
static inline struct iommu_domain *intel_svm_domain_alloc(void)
{
return NULL;
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index bb8316fec1aa..bdde38a5e43a 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4720,21 +4720,29 @@ static void intel_iommu_remove_dev_pasid(struct device *dev, ioasid_t pasid)
struct intel_iommu *iommu = device_to_iommu(dev, NULL, NULL);
struct iommu_domain *domain;
- /* Domain type specific cleanup: */
domain = iommu_get_domain_for_dev_pasid(dev, pasid, 0);
- if (domain) {
- switch (domain->type) {
- case IOMMU_DOMAIN_SVA:
- intel_svm_remove_dev_pasid(dev, pasid);
- break;
- default:
- /* should never reach here */
- WARN_ON(1);
- break;
- }
+ if (WARN_ON_ONCE(!domain))
+ goto out_tear_down;
+
+ /*
+ * The SVA implementation needs to handle its own stuffs like the mm
+ * notification. Before consolidating that code into iommu core, let
+ * the intel sva code handle it.
+ */
+ if (domain->type == IOMMU_DOMAIN_SVA) {
+ intel_svm_remove_dev_pasid(dev, pasid);
+ goto out_tear_down;
}
+ /*
+ * Should never reach here until we add support for attaching
+ * non-SVA domain to a pasid.
+ */
+ WARN_ON(1);
+
+out_tear_down:
intel_pasid_tear_down_entry(iommu, dev, pasid, false);
+ intel_drain_pasid_prq(dev, pasid);
}
const struct iommu_ops intel_iommu_ops = {
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 2a82864e9d57..9fbae9af6615 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -26,8 +26,6 @@
#include "trace.h"
static irqreturn_t prq_event_thread(int irq, void *d);
-static void intel_svm_drain_prq(struct device *dev, u32 pasid);
-#define to_intel_svm_dev(handle) container_of(handle, struct intel_svm_dev, sva)
static DEFINE_XARRAY_ALLOC(pasid_private_array);
static int pasid_private_add(ioasid_t pasid, void *priv)
@@ -382,17 +380,6 @@ void intel_svm_remove_dev_pasid(struct device *dev, u32 pasid)
if (sdev) {
list_del_rcu(&sdev->list);
- /*
- * Flush the PASID cache and IOTLB for this device.
- * Note that we do depend on the hardware *not* using
- * the PASID any more. Just as we depend on other
- * devices never using PASIDs that they have no right
- * to use. We have a *shared* PASID table, because it's
- * large and has to be physically contiguous. So it's
- * hard to be as defensive as we might like.
- */
- intel_pasid_tear_down_entry(iommu, dev, svm->pasid, false);
- intel_svm_drain_prq(dev, svm->pasid);
kfree_rcu(sdev, rcu);
if (list_empty(&svm->devs)) {
@@ -449,7 +436,7 @@ static bool is_canonical_address(u64 addr)
}
/**
- * intel_svm_drain_prq - Drain page requests and responses for a pasid
+ * intel_drain_pasid_prq - Drain page requests and responses for a pasid
* @dev: target device
* @pasid: pasid for draining
*
@@ -463,7 +450,7 @@ static bool is_canonical_address(u64 addr)
* described in VT-d spec CH7.10 to drain all page requests and page
* responses pending in the hardware.
*/
-static void intel_svm_drain_prq(struct device *dev, u32 pasid)
+void intel_drain_pasid_prq(struct device *dev, u32 pasid)
{
struct device_domain_info *info;
struct dmar_domain *domain;
--
2.34.1
next prev parent reply other threads:[~2023-08-09 12:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 12:47 [PATCH 00/13] [PULL REQUEST] Intel IOMMU updates for Linux v6.6 Lu Baolu
2023-08-09 12:47 ` [PATCH 01/13] iommu: Generalize PASID 0 for normal DMA w/o PASID Lu Baolu
2023-08-09 12:47 ` [PATCH 02/13] iommu: Move global PASID allocation from SVA to core Lu Baolu
2023-08-09 12:47 ` [PATCH 03/13] iommu/vt-d: Add domain_flush_pasid_iotlb() Lu Baolu
2023-08-09 12:47 ` [PATCH 04/13] iommu/vt-d: Remove pasid_mutex Lu Baolu
2023-08-09 12:47 ` Lu Baolu [this message]
2023-08-09 12:47 ` [PATCH 06/13] iommu/vt-d: Prepare for set_dev_pasid callback Lu Baolu
2023-08-09 12:48 ` [PATCH 07/13] iommu/vt-d: Add set_dev_pasid callback for dma domain Lu Baolu
2023-08-09 12:48 ` [PATCH 08/13] dmaengine/idxd: Re-enable kernel workqueue under DMA API Lu Baolu
2023-08-09 12:48 ` [PATCH 09/13] iommu: Prevent RESV_DIRECT devices from blocking domains Lu Baolu
2023-08-09 12:48 ` [PATCH 10/13] iommu/vt-d: Remove rmrr check in domain attaching device path Lu Baolu
2023-08-09 12:48 ` [PATCH 11/13] iommu/vt-d: Fix to flush cache of PASID directory table Lu Baolu
2023-08-09 12:48 ` [PATCH 12/13] iommu/vt-d: Fix to convert mm pfn to dma pfn Lu Baolu
2023-08-09 12:48 ` [PATCH 13/13] iommu/vt-d: Remove unused extern declaration dmar_parse_dev_scope() Lu Baolu
2023-08-09 15:47 ` [PATCH 00/13] [PULL REQUEST] Intel IOMMU updates for Linux v6.6 Joerg Roedel
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=20230809124806.45516-6-baolu.lu@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.jun.pan@linux.intel.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yanfei.xu@intel.com \
--cc=yuehaibing@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox