2cb3d041cd
Move to kernel version 5.10 using source from the Yocto Project. 1. Add STX patches for kernel 5.10. 2. Support git source for linux-yocto. 3. Add build_srpm from build-tools/default_build_srpm and modified for git repo from yocto 4. Modify std and rt config files. 5. Build python-perf instead of python3-perf for std kernel. python-perf is needed by tuned-2.8.0-5.el7.noarch. 6. Modify rt spec to build out package kernel-rt-tools and kernel-rt-kvm. 7. Add kernel-5.10.30-x86_64-rt.config.tis_extra and kernel-5.10.30-x86_64.config.tis_extra 8. Add a dist field to avoid undesired rebuilds. 9. Ensure -unsigned package is populated Story: 2008921 Partial-Task: 42519 Signed-off-by: Jackie Huang <jackie.huang@windriver.com> Signed-off-by: Vefa Bicakci <vefa.bicakci@windriver.com> Signed-off-by: Jiping Ma <jiping.ma2@windriver.com> Change-Id: Id1f635302f265826f7ff2860a3bed4b7755b2888
126 lines
5.3 KiB
Diff
126 lines
5.3 KiB
Diff
From c35ee3034b61e72bf9fef888a3c4702049a77bcc Mon Sep 17 00:00:00 2001
|
|
From: Matt Peters <matt.peters@windriver.com>
|
|
Date: Mon, 30 May 2016 10:51:02 -0400
|
|
Subject: [PATCH] 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: Jim Somerville <Jim.Somerville@windriver.com>
|
|
Signed-off-by: Zhang Zhiguo <zhangzhg@neusoft.com>
|
|
Signed-off-by: Dongqi Chen <chen.dq@neusoft.com>
|
|
[lz: Adapted the patch for context changes.]
|
|
Signed-off-by: Li Zhou <li.zhou@windriver.com>
|
|
[jp: fix warning: this 'else' clause does not guard]
|
|
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
|
|
---
|
|
.../admin-guide/kernel-parameters.txt | 5 +++++
|
|
Documentation/x86/intel-iommu.rst | 18 +++++++++++++++
|
|
drivers/iommu/intel/iommu.c | 22 ++++++++++++++++++-
|
|
3 files changed, 44 insertions(+), 1 deletion(-)
|
|
|
|
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
|
|
index 78a923d087c1..e7639eaa41b8 100644
|
|
--- a/Documentation/admin-guide/kernel-parameters.txt
|
|
+++ b/Documentation/admin-guide/kernel-parameters.txt
|
|
@@ -1861,6 +1861,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/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst
|
|
index 099f13d51d5f..18e6a8d8b1ee 100644
|
|
--- a/Documentation/x86/intel-iommu.rst
|
|
+++ b/Documentation/x86/intel-iommu.rst
|
|
@@ -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/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
|
|
index db9bf5ac0722..f30df770243d 100644
|
|
--- a/drivers/iommu/intel/iommu.c
|
|
+++ b/drivers/iommu/intel/iommu.c
|
|
@@ -354,6 +354,7 @@ static int dmar_map_gfx = 1;
|
|
static int dmar_forcedac;
|
|
static int intel_iommu_strict;
|
|
static int intel_iommu_superpage = 1;
|
|
+static int intel_iommu_ethrmrr = 1;
|
|
static int iommu_identity_mapping;
|
|
static int intel_no_bounce;
|
|
static int iommu_skip_te_disable;
|
|
@@ -448,6 +449,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_default_passthrough()) {
|
|
+ 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;
|
|
@@ -2907,8 +2917,18 @@ static bool device_rmrr_is_relaxable(struct device *dev)
|
|
pdev = to_pci_dev(dev);
|
|
if (IS_USB_DEVICE(pdev) || IS_GFX_DEVICE(pdev))
|
|
return true;
|
|
- else
|
|
+ else {
|
|
+ /* 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 true;
|
|
return false;
|
|
+ }
|
|
}
|
|
|
|
/*
|
|
--
|
|
2.29.2
|
|
|