From d72c68c72ecef169b3a01c2623ef7b4542449aa6 Mon Sep 17 00:00:00 2001 Message-Id: In-Reply-To: <0bd66eb88c950d172a7dcefc61cb2e89b89cacce.1507911922.git.Jim.Somerville@windriver.com> References: <0bd66eb88c950d172a7dcefc61cb2e89b89cacce.1507911922.git.Jim.Somerville@windriver.com> From: Matt Peters Date: Mon, 30 May 2016 10:51:02 -0400 Subject: [PATCH 05/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 [PG: Added bootarg wrapper and documentation entries.] Signed-off-by: Paul Gortmaker Signed-off-by: Nam Ninh Signed-off-by: Nam Ninh Signed-off-by: Jim Somerville --- Documentation/Intel-IOMMU.txt | 18 ++++++++++++++++++ Documentation/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 cf9431d..1dcc349 100644 --- a/Documentation/Intel-IOMMU.txt +++ b/Documentation/Intel-IOMMU.txt @@ -32,6 +32,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/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d723499..907487a 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1267,6 +1267,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 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 171a8b2..e763e78 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -496,6 +496,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; /* We only actually use ECS when PASID support (on the new bit 40) * is also advertised. Some early implementations — the ones with @@ -555,6 +556,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; @@ -2674,6 +2684,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; -- 1.8.3.1