summaryrefslogtreecommitdiff
path: root/include/linux/intel-svm.h
diff options
context:
space:
mode:
authorDavid Woodhouse <David.Woodhouse@intel.com>2015-10-15 17:52:15 +0300
committerDavid Woodhouse <David.Woodhouse@intel.com>2015-10-15 17:52:21 +0300
commit5cec753709adf1a20c8b15edf8e5245cf4fd4e82 (patch)
tree9a600f9f1addd96d4ae4a536a53b33c0d58ba2e8 /include/linux/intel-svm.h
parent569e4f7782fb92d0e1b395b5fb01de642dd74dcf (diff)
downloadlinux-5cec753709adf1a20c8b15edf8e5245cf4fd4e82.tar.xz
iommu/vt-d: Implement SVM_FLAG_SUPERVISOR_MODE for kernel access
This is only usable for the static 1:1 mapping of physical memory. Any access to vmalloc or module regions will require some way of doing an IOTLB flush. It's theoretically possible to hook into the tlb_flush_kernel_range() function, but that seems like overkill — most of the addresses accessed through a kernel PASID *will* be in the 1:1 mapping. If we really need to allow access to more interesting kernel regions, then the answer will probably be an explicit IOTLB flush call after use, akin to the DMA API's unmap function. In fact, it might be worth introducing that sooner rather than later, and making it just BUG() if the address isn't in the static 1:1 mapping. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Diffstat (limited to 'include/linux/intel-svm.h')
-rw-r--r--include/linux/intel-svm.h15
1 files changed, 14 insertions, 1 deletions
diff --git a/include/linux/intel-svm.h b/include/linux/intel-svm.h
index dd94ab45a4db..0a48ccff24ae 100644
--- a/include/linux/intel-svm.h
+++ b/include/linux/intel-svm.h
@@ -40,7 +40,20 @@ struct svm_dev_ops {
* disambiguate between multiple device contexts which access the same MM,
* if there is no other way to do so. It should be used sparingly, if at all.
*/
-#define SVM_FLAG_PRIVATE_PASID (1<<0)
+#define SVM_FLAG_PRIVATE_PASID (1<<0)
+
+/*
+ * The SVM_FLAG_SUPERVISOR_MODE flag requests a PASID which can be used only
+ * for access to kernel addresses. No IOTLB flushes are automatically done
+ * for kernel mappings; it is valid only for access to the kernel's static
+ * 1:1 mapping of physical memory — not to vmalloc or even module mappings.
+ * A future API addition may permit the use of such ranges, by means of an
+ * explicit IOTLB flush call (akin to the DMA API's unmap method).
+ *
+ * It is unlikely that we will ever hook into flush_tlb_kernel_range() to
+ * do such IOTLB flushes automatically.
+ */
+#define SVM_FLAG_SUPERVISOR_MODE (1<<1)
/**
* intel_svm_bind_mm() - Bind the current process to a PASID