kernel/kernel-std/centos/patches/intel-iommu-allow-ignoring-Ethernet-device-RMRR-with.patch

From c449e4c490ac85ccf04e8aab67c8120aa48f8ad0 Mon Sep 17 00:00:00 2001
Message-Id: <c449e4c490ac85ccf04e8aab67c8120aa48f8ad0.1527544850.git.Jim.Somerville@windriver.com>
In-Reply-To: <b6ceef1c915827b50ce3f76da4dc47f3eb768b44.1527544850.git.Jim.Somerville@windriver.com>
References: <b6ceef1c915827b50ce3f76da4dc47f3eb768b44.1527544850.git.Jim.Somerville@windriver.com>
From: Matt Peters <matt.peters@windriver.com>
Date: Mon, 30 May 2016 10:51:02 -0400
Subject: [PATCH 08/26] intel-iommu: allow ignoring Ethernet device RMRR with
 IOMMU passthrough

Some BIOS's are reporting DMAR RMRR entries for Ethernet devices
which is causing problems when PCI passthrough is enabled.  These
devices should be able to use the static identity map since the
host should not be enforcing specific address ranges when IOMMU
passthrough is enabled.

Originally-by: Matt Peters <matt.peters@windriver.com>
[PG: Added bootarg wrapper and documentation entries.]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Nam Ninh <nam.ninh@windriver.com>

Signed-off-by: Nam Ninh <nam.ninh@windriver.com>
Signed-off-by: Jim Somerville <Jim.Somerville@windriver.com>
Signed-off-by: Zhang Zhiguo <zhangzhg@neusoft.com>

---
 Documentation/Intel-IOMMU.txt                 | 18 ++++++++++++++++++
 .../admin-guide/kernel-parameters.txt         |  5 +++++
 drivers/iommu/intel-iommu.c                   | 19 +++++++++++++++++++
 3 files changed, 42 insertions(+)

diff --git a/Documentation/Intel-IOMMU.txt b/Documentation/Intel-IOMMU.txt
index 9dae6b4..1080fcb 100644
--- a/Documentation/Intel-IOMMU.txt
+++ b/Documentation/Intel-IOMMU.txt
@@ -33,6 +33,24 @@ regions will fail. Hence BIOS uses RMRR to specify these regions along with
 devices that need to access these regions. OS is expected to setup
 unity mappings for these regions for these devices to access these regions.
 
+RMRR for other devices?
+-----------------------
+
+There are reports of BIOS out there that indicate RMRR regions for things
+like ethernet devices.  As per mainline commit c875d2c1b8083 ("iommu/vt-d:
+Exclude devices using RMRRs from IOMMU API domains") such a device is
+"fundamentally incompatible" with the IOMMU API and "we must prevent such
+devices from being used by the IOMMU API."  However, in the event that
+the RMRR indicated by the BIOS is assumed to be just a reporting error,
+there is an additional iommu boot arg that can be used to ignore RMRR
+settings for ethernet, i.e. "intel_iommu=on,eth_no_rmrr iommu=pt".
+Note that iommu=pt is required in order to eth_no_rmrr to have effect.
+
+If you use this setting, you should consult with your hardware vendor to
+confirm that it is just a reporting error, and that it truly is not
+actively using any DMA to/from RMRR, as otherwise system instability
+may result.
+
 How is IOVA generated?
 ----------------------
 
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 2f4a7ad..c11ebc3 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1651,6 +1651,11 @@
 			than 32-bit addressing. The default is to look
 			for translation below 32-bit and if not available
 			then look in the higher range.
+		eth_no_rmrr [Default Off]
+			With this option provided, the kernel will ignore
+			any specified RMRR regions specified by the BIOS
+			for PCI ethernet devices.  Confirm with your hardware
+			vendor the RMRR regions are indeed invalid first.
 		strict [Default Off]
 			With this option on every unmap_single operation will
 			result in a hardware IOTLB flush operation as opposed
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 7e9f1db..a28bafe 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -485,6 +485,7 @@ static int dmar_forcedac;
 static int intel_iommu_strict;
 static int intel_iommu_superpage = 1;
 static int intel_iommu_ecs = 1;
+static int intel_iommu_ethrmrr = 1;
 static int intel_iommu_pasid28;
 static int iommu_identity_mapping;
 
@@ -569,6 +570,15 @@ static int __init intel_iommu_setup(char *str)
 		} else if (!strncmp(str, "forcedac", 8)) {
 			pr_info("Forcing DAC for PCI devices\n");
 			dmar_forcedac = 1;
+		} else if (!strncmp(str, "eth_no_rmrr", 11)) {
+			if (!iommu_pass_through) {
+				printk(KERN_WARNING
+					"Intel-IOMMU: error - eth_no_rmrr requires iommu=pt\n");
+			} else {
+				printk(KERN_INFO
+					"Intel-IOMMU: ignoring ethernet RMRR values\n");
+				intel_iommu_ethrmrr = 0;
+			}
 		} else if (!strncmp(str, "strict", 6)) {
 			pr_info("Disable batched IOTLB flush\n");
 			intel_iommu_strict = 1;
@@ -2917,6 +2927,15 @@ static bool device_is_rmrr_locked(struct device *dev)
 
 		if (IS_USB_DEVICE(pdev) || IS_GFX_DEVICE(pdev))
 			return false;
+		/* As a temporary workaround for issues seen on ProLiant DL380p,
+		 * allow the operator to ignore the RMRR settings for ethernet
+		 * devices.  Ideally the end user should contact their vendor
+		 * regarding why there are RMRR, as per mainline c875d2c1b8083
+		 * ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains")
+		 * it seems that these make no sense at all.
+		 */
+		if ((pdev->class >> 8) == PCI_CLASS_NETWORK_ETHERNET && !intel_iommu_ethrmrr)
+			return false;
 	}
 
 	return true;
-- 
2.18.1