Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1494748rwb; Thu, 8 Dec 2022 11:20:47 -0800 (PST) X-Google-Smtp-Source: AA0mqf4MSk9BSU8fie0XaRLJBhPN7Ye93CgKiReaU+MxOMmetpXqf0SKE+kM2D0wyH0MGvguRYu2 X-Received: by 2002:a17:902:bcc5:b0:189:6d55:91a8 with SMTP id o5-20020a170902bcc500b001896d5591a8mr59615153pls.127.1670527246904; Thu, 08 Dec 2022 11:20:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670527246; cv=none; d=google.com; s=arc-20160816; b=b51nsPqnBiIFuOnnuH28wAe8OBCpZo4KaIsTnphSXdn7x8aHr0BJpjFmvsjBHXDTwO rxdHoS8qMPN5+LhEDQamltsl7N2kPva/zQeV1KylUV8TP0bkcESKrqrmwUiZMEIgKkMj 1LgUwjc7zFTm3xx0//NDwK4vtSTnNNtaDB8zfiTPN1RVC3JNY6gacwyX13PM1CD5nV+d Kav05aLD7ERQDx6ePSsDLM/EZAcn3RcODbr0xBM+NuwdujsOu1Tz26kiYUfHR6euDOoi HZ9505zN8UmdCTEUqWtL4EDNNjcMP7Pv3t9AIlvz+ghpDFIKvu26vhMXY5AjCbLpRQE/ NVPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=2ofh3MSOOfESB0WX4MXBivpsHwsziLAbP+tiv8sqe34=; b=H+0JTKJCkbBscDs5kIMsyOQjCDAor8uK4tnxdITLESiqrf9PR1a05QFVZcP9HlQyHK frHYbbAjwmAiEAf0rxhnuv8R7B/EDoKy8l2xmLDTxm9UQ+hwEf/WpasEnkCv71yaMECj FHWCXOC1xZdoaSY+ltJXoKIwrAELeuevEaFPBDrfNlpLsMuBUbr5AREUJaYDlWX8CybC g7TgDbtTPp6X7itFnLJboqFcBzzuyxLf0zB7OvjPH1sxs+ebEMjSaJvmH7SxkNXtAzVh B9YxAsRy49koDzaS1mhjT6+6vDGHCVCrIF2l46EjDA/w95mVPyMJ9YiT83b9IM73X5mu ZQEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HcYSMsmE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r23-20020a63a557000000b0046af2452ed8si24473524pgu.766.2022.12.08.11.20.37; Thu, 08 Dec 2022 11:20:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=HcYSMsmE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229940AbiLHTDw (ORCPT + 73 others); Thu, 8 Dec 2022 14:03:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229462AbiLHTDu (ORCPT ); Thu, 8 Dec 2022 14:03:50 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8608D8DFF3; Thu, 8 Dec 2022 11:03:49 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 263E0B825E5; Thu, 8 Dec 2022 19:03:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91283C433F0; Thu, 8 Dec 2022 19:03:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670526226; bh=94W/beXAHAD9dN/LgrT9hR5vmz5L5kct+KScNhLaOgQ=; h=From:To:Cc:Subject:Date:From; b=HcYSMsmEkHd/IW97n6EKouw1E7Nt8jYTsp+VszEz3jMWmEOC5GapqO5WN+z4h2QjG eIaqsGBuwovVRMHzyCfu/pwtJvZ1SSFp2PPQCpblmnXFtKNkQdQKIds1m/wLQBaQub Fy7OVxVXN9npyNSuPFlnh9n0k9C2mvV6Wmwntnra8UjNS15W5plPx6tRK8iTJ5IDdE iKNzNqfNm5f6eBc2zizQ1oTOFnTYXOTthjs6RNSG5wYMYCypshylX4ZB33xPv6Xv3Y 5SzUfYwlrLo3E8uE8onhAD2CsnD2etnqPilqJ8cFcUvJsWZ5zltvfbdV9TKa88B3cK D4nCFls88kvJA== From: Bjorn Helgaas To: linux-pci@vger.kernel.org Cc: Hans de Goede , Florent DELAHAYE , Konrad J Hambrick , Matt Hansen <2lprbe78@duck.com>, =?UTF-8?q?Benoit=20Gr=C3=A9goire?= , Nicholas Johnson , Mika Westerberg , Werner Sembach , mumblingdrunkard@protonmail.com, linux-kernel@vger.kernel.org, Bjorn Helgaas Subject: [PATCH v2 0/4] PCI: Continue E820 vs host bridge window saga Date: Thu, 8 Dec 2022 13:03:37 -0600 Message-Id: <20221208190341.1560157-1-helgaas@kernel.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Bjorn Helgaas When allocating space for PCI BARs, Linux avoids allocating space mentioned in the E820 map. This was originally done by 4dc2287c1805 ("x86: avoid E820 regions when allocating address space") to work around BIOS defects that included unusable space in host bridge _CRS. Some recent machines use EfiMemoryMappedIO for PCI MMCONFIG and host bridge apertures, and bootloaders and EFI stubs convert those to E820 regions, which means we can't allocate space for hot-added PCI devices (often a dock) or for devices the BIOS didn't configure (often a touchpad) The current strategy is to add DMI quirks that disable the E820 filtering on these machines and to disable it entirely starting with 2023 BIOSes: d341838d776a ("x86/PCI: Disable E820 reserved region clipping via quirks") 0ae084d5a674 ("x86/PCI: Disable E820 reserved region clipping starting in 2023") But the quirks are problematic because it's really hard to list all the machines that need them. This series is an attempt at a more generic approach. I'm told by firmware folks that EfiMemoryMappedIO means "the OS should map this area so EFI runtime services can use it in virtual mode," but does not prevent the OS from using it. The first patch removes large EfiMemoryMappedIO areas from the E820 map. This doesn't affect any virtual mapping of those areas (that would have to be done directly from the EFI memory map) but it means Linux can allocate space for PCI MMIO. The rest are basically cosmetic log message changes. Changes from v1 to v2: - Remove only large (>= 256KB) EfiMemoryMappedIO areas from E820 to avoid the Lenovo X1 Carbon suspend/resume problems. This machine includes 64KB of non-window space in the PNP0A03 _CRS, and a corresponding EfiMemoryMappedIO area seems to be the only clue to avoid it (see https://bugzilla.redhat.com/show_bug.cgi?id=2029207). Interdiff below. Bjorn Helgaas (4): efi/x86: Remove EfiMemoryMappedIO from E820 map PCI: Skip allocate_resource() if too little space available x86/PCI: Tidy E820 removal messages x86/PCI: Fix log message typo arch/x86/kernel/resource.c | 8 +++++-- arch/x86/pci/acpi.c | 2 +- arch/x86/platform/efi/efi.c | 46 +++++++++++++++++++++++++++++++++++++ drivers/pci/bus.c | 4 ++++ 4 files changed, 57 insertions(+), 3 deletions(-) -- 2.25.1 diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 4728f60119da..dee1852e95cd 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -315,8 +315,12 @@ static void __init efi_clean_memmap(void) * PCI host bridge windows, which means Linux can't allocate BAR space for * hot-added devices. * - * Remove any EfiMemoryMappedIO regions from the E820 map to avoid this + * 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) { @@ -327,11 +331,17 @@ static void __init efi_remove_e820_mmio(void) for_each_efi_memory_desc(md) { if (md->type == EFI_MEMORY_MAPPED_IO) { size = md->num_pages << EFI_PAGE_SHIFT; - 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); + 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++; }