public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: linux-pci@vger.kernel.org
Cc: "Hans de Goede" <hdegoede@redhat.com>,
	"Florent DELAHAYE" <kernelorg@undead.fr>,
	"Konrad J Hambrick" <kjhambrick@gmail.com>,
	"Matt Hansen" <2lprbe78@duck.com>,
	"Benoit Grégoire" <benoitg@coeus.ca>,
	"Nicholas Johnson" <nicholas.johnson-opensource@outlook.com.au>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Werner Sembach" <wse@tuxedocomputers.com>,
	mumblingdrunkard@protonmail.com, linux-kernel@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>
Subject: [PATCH v2 1/4] efi/x86: Remove EfiMemoryMappedIO from E820 map
Date: Thu,  8 Dec 2022 13:03:38 -0600	[thread overview]
Message-ID: <20221208190341.1560157-2-helgaas@kernel.org> (raw)
In-Reply-To: <20221208190341.1560157-1-helgaas@kernel.org>

From: Bjorn Helgaas <bhelgaas@google.com>

Firmware can use EfiMemoryMappedIO to request that MMIO regions be mapped
by the OS so they can be accessed by EFI runtime services, but should have
no other significance to the OS (UEFI r2.10, sec 7.2).  However, most
bootloaders and EFI stubs convert EfiMemoryMappedIO regions to
E820_TYPE_RESERVED entries, which prevent Linux from allocating space from
them (see remove_e820_regions()).

Some platforms use EfiMemoryMappedIO entries for PCI MMCONFIG space and PCI
host bridge windows, which means Linux can't allocate BAR space for
hot-added devices.

Remove large EfiMemoryMappedIO regions from the E820 map to avoid this
problem.

Leave small (< 256KB) EfiMemoryMappedIO regions alone because on some
platforms, these describe non-window space that's included in host bridge
_CRS.  If we assign that space to PCI devices, they don't work.  On the
Lenovo X1 Carbon, this leads to suspend/resume failures.

The previous solution to the problem of allocating BARs in these regions
was to add pci_crs_quirks[] entries to disable E820 checking for these
machines (see d341838d776a ("x86/PCI: Disable E820 reserved region clipping
via quirks")):

  Acer   DMI_PRODUCT_NAME    Spin SP513-54N
  Clevo  DMI_BOARD_NAME      X170KM-G
  Lenovo DMI_PRODUCT_VERSION *IIL*

Florent reported the BAR allocation issue on the Clevo NL4XLU.  We could
add another quirk for the NL4XLU, but I hope this generic change can solve
it for many machines without having to add quirks.

This change has been tested on Clevo X170KM-G (Konrad) and Lenovo Ideapad
Slim 3 (Matt) and solves the problem even when overriding the existing
quirks by booting with "pci=use_e820".

Link: https://bugzilla.kernel.org/show_bug.cgi?id=216565     Clevo NL4XLU
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206459#c78 Clevo X170KM-G
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1868899    Ideapad Slim 3
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2029207    X1 Carbon
Reported-by: Florent DELAHAYE <kernelorg@undead.fr>
Tested-by: Konrad J Hambrick <kjhambrick@gmail.com>
Tested-by: Matt Hansen <2lprbe78@duck.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Hans de Goede <hdegoede@redhat.com>
---
 arch/x86/platform/efi/efi.c | 46 +++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ebc98a68c400..dee1852e95cd 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -303,6 +303,50 @@ static void __init efi_clean_memmap(void)
 	}
 }
 
+/*
+ * Firmware can use EfiMemoryMappedIO to request that MMIO regions be
+ * mapped by the OS so they can be accessed by EFI runtime services, but
+ * should have no other significance to the OS (UEFI r2.10, sec 7.2).
+ * However, most bootloaders and EFI stubs convert EfiMemoryMappedIO
+ * regions to E820_TYPE_RESERVED entries, which prevent Linux from
+ * allocating space from them (see remove_e820_regions()).
+ *
+ * Some platforms use EfiMemoryMappedIO entries for PCI MMCONFIG space and
+ * PCI host bridge windows, which means Linux can't allocate BAR space for
+ * hot-added devices.
+ *
+ * Remove large EfiMemoryMappedIO regions from the E820 map to avoid this
+ * problem.
+ *
+ * Retain small EfiMemoryMappedIO regions because on some platforms, these
+ * describe non-window space that's included in host bridge _CRS.  If we
+ * assign that space to PCI devices, they don't work.
+ */
+static void __init efi_remove_e820_mmio(void)
+{
+	efi_memory_desc_t *md;
+	u64 size, start, end;
+	int i = 0;
+
+	for_each_efi_memory_desc(md) {
+		if (md->type == EFI_MEMORY_MAPPED_IO) {
+			size = md->num_pages << EFI_PAGE_SHIFT;
+			if (size >= 256*1024) {
+				start = md->phys_addr;
+				end = start + size - 1;
+				pr_info("Remove mem%02u: MMIO range=[0x%08llx-0x%08llx] (%lluMB) from e820 map\n",
+					i, start, end, size >> 20);
+				e820__range_remove(start, size,
+						   E820_TYPE_RESERVED, 1);
+			} else {
+				pr_info("Not removing mem%02u: MMIO range=[0x%08llx-0x%08llx] (%lluKB) from e820 map\n",
+					i, start, end, size >> 10);
+			}
+		}
+		i++;
+	}
+}
+
 void __init efi_print_memmap(void)
 {
 	efi_memory_desc_t *md;
@@ -474,6 +518,8 @@ void __init efi_init(void)
 	set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
 	efi_clean_memmap();
 
+	efi_remove_e820_mmio();
+
 	if (efi_enabled(EFI_DBG))
 		efi_print_memmap();
 }
-- 
2.25.1


  reply	other threads:[~2022-12-08 19:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08 19:03 [PATCH v2 0/4] PCI: Continue E820 vs host bridge window saga Bjorn Helgaas
2022-12-08 19:03 ` Bjorn Helgaas [this message]
2022-12-09  8:06   ` [PATCH v2 1/4] efi/x86: Remove EfiMemoryMappedIO from E820 map Hans de Goede
2022-12-09 11:04     ` Hans de Goede
2022-12-09 20:10       ` Bjorn Helgaas
2023-01-13 10:46   ` Baowen Zheng
2023-01-13 13:54     ` [PATCH " Bjorn Helgaas
2022-12-08 19:03 ` [PATCH v2 2/4] PCI: Skip allocate_resource() if too little space available Bjorn Helgaas
2022-12-08 19:03 ` [PATCH v2 3/4] x86/PCI: Tidy E820 removal messages Bjorn Helgaas
2022-12-09 18:42   ` Andy Shevchenko
2022-12-09 20:34     ` Bjorn Helgaas
2022-12-09 21:33       ` Andy Shevchenko
2022-12-08 19:03 ` [PATCH v2 4/4] x86/PCI: Fix log message typo Bjorn Helgaas
2022-12-09 18:43   ` Andy Shevchenko
2022-12-09 20:51     ` Bjorn Helgaas
2022-12-09 21:35       ` Andy Shevchenko
2022-12-09 21:52         ` Bjorn Helgaas
2022-12-10 20:55           ` Andy Shevchenko
2022-12-08 20:03 ` [PATCH v2 0/4] PCI: Continue E820 vs host bridge window saga Hans de Goede

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=20221208190341.1560157-2-helgaas@kernel.org \
    --to=helgaas@kernel.org \
    --cc=2lprbe78@duck.com \
    --cc=benoitg@coeus.ca \
    --cc=bhelgaas@google.com \
    --cc=hdegoede@redhat.com \
    --cc=kernelorg@undead.fr \
    --cc=kjhambrick@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mumblingdrunkard@protonmail.com \
    --cc=nicholas.johnson-opensource@outlook.com.au \
    --cc=wse@tuxedocomputers.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