From patchwork Mon Feb 14 15:17:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 543422 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73117C433EF for ; Mon, 14 Feb 2022 15:18:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355722AbiBNPSj (ORCPT ); Mon, 14 Feb 2022 10:18:39 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:45028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355719AbiBNPSi (ORCPT ); Mon, 14 Feb 2022 10:18:38 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 524FDBF72 for ; Mon, 14 Feb 2022 07:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644851909; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=imdRsem3qir45ShJ5Znqcxhg95us/ubvR7ZXPO/Mh9w=; b=G/lafYGFl5pdDJ5fbJEPny4/XE+gmZz8DL73ULjSC2n21S8I1f0ZA8Gk9FZ6KycfYtsunn aQ4rwm5iJWPZjX2kZdgjODJZTwsCObcz/WyVDj1wwZR3oDOrfaoCHmDQcPT4qYdWPDDMdy UwCITjrbykQP3Rt+omREKi5pDpvTInw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-313-s1K7PUI9PIuJH-f9Bm_bUw-1; Mon, 14 Feb 2022 10:18:26 -0500 X-MC-Unique: s1K7PUI9PIuJH-f9Bm_bUw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 08C50814243; Mon, 14 Feb 2022 15:18:24 +0000 (UTC) Received: from x1.localdomain.com (unknown [10.39.192.237]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3CFDE2A19C; Mon, 14 Feb 2022 15:18:18 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Bjorn Helgaas , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" Cc: Hans de Goede , Mika Westerberg , =?utf-8?q?Krzysztof_Wilc?= =?utf-8?q?zy=C5=84ski?= , Myron Stowe , Juha-Pekka Heikkila , =?utf-8?q?Benoit_Gr?= =?utf-8?q?=C3=A9goire?= , Hui Wang , linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: [RFC 1/2] x86/e820: Map EFI_MEMORY_MAPPED_IO to a new E820_TYPE_MMIO type Date: Mon, 14 Feb 2022 16:17:58 +0100 Message-Id: <20220214151759.98267-2-hdegoede@redhat.com> In-Reply-To: <20220214151759.98267-1-hdegoede@redhat.com> References: <20220214151759.98267-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Map EFI_MEMORY_MAPPED_IO to a new E820_TYPE_MMIO type. The EFI memory-map has a special type for Memory Mapped IO, add a new E820_TYPE_MMIO type and when translating the EFI memory-map to an e820_table map EFI_MEMORY_MAPPED_IO to this new E820_TYPE_MMIO type. This is a preparation patch for making arch_remove_reservations() treat EFI_MEMORY_MAPPED_IO ranges differently then other reserved ranged. All users of E820_TYPE_* have been audited and modified where necessary so that this patch should not introduce any functional changes. Signed-off-by: Hans de Goede --- arch/x86/include/asm/e820/types.h | 3 +++ arch/x86/include/asm/iommu.h | 3 ++- arch/x86/kernel/e820.c | 5 +++++ arch/x86/mm/ioremap.c | 1 + arch/x86/pci/mmconfig-shared.c | 15 +++++++++++---- arch/x86/platform/efi/efi.c | 5 ++++- drivers/firmware/efi/libstub/x86-stub.c | 5 ++++- 7 files changed, 30 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/e820/types.h b/arch/x86/include/asm/e820/types.h index 314f75d886d0..d91d4d28fe50 100644 --- a/arch/x86/include/asm/e820/types.h +++ b/arch/x86/include/asm/e820/types.h @@ -44,6 +44,9 @@ enum e820_type { * might alter over the S3 transition: */ E820_TYPE_RESERVED_KERN = 128, + + /* Used for EFI_MEMORY_MAPPED_IO when translating the EFI memmap */ + E820_TYPE_MMIO = 129, }; /* diff --git a/arch/x86/include/asm/iommu.h b/arch/x86/include/asm/iommu.h index bf1ed2ddc74b..ed7329137fef 100644 --- a/arch/x86/include/asm/iommu.h +++ b/arch/x86/include/asm/iommu.h @@ -18,7 +18,8 @@ arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr) u64 start = rmrr->base_address; u64 end = rmrr->end_address + 1; - if (e820__mapped_all(start, end, E820_TYPE_RESERVED)) + if (e820__mapped_all(start, end, E820_TYPE_RESERVED) || + e820__mapped_all(start, end, E820_TYPE_MMIO)) return 0; pr_err(FW_BUG "No firmware reserved region can cover this RMRR [%#018Lx-%#018Lx], contact BIOS vendor for fixes\n", diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index bc0657f0deed..5fbd2505b10e 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -196,6 +196,7 @@ static void __init e820_print_type(enum e820_type type) case E820_TYPE_UNUSABLE: pr_cont("unusable"); break; case E820_TYPE_PMEM: /* Fall through: */ case E820_TYPE_PRAM: pr_cont("persistent (type %u)", type); break; + case E820_TYPE_MMIO: pr_cont("MMIO"); break; default: pr_cont("type %u", type); break; } } @@ -1064,6 +1065,7 @@ static const char *__init e820_type_to_string(struct e820_entry *entry) case E820_TYPE_PMEM: return "Persistent Memory"; case E820_TYPE_RESERVED: return "Reserved"; case E820_TYPE_SOFT_RESERVED: return "Soft Reserved"; + case E820_TYPE_MMIO: return "Memory Mapped IO"; default: return "Unknown E820 type"; } } @@ -1080,6 +1082,7 @@ static unsigned long __init e820_type_to_iomem_type(struct e820_entry *entry) case E820_TYPE_PMEM: /* Fall-through: */ case E820_TYPE_RESERVED: /* Fall-through: */ case E820_TYPE_SOFT_RESERVED: /* Fall-through: */ + case E820_TYPE_MMIO: /* Fall-through: */ default: return IORESOURCE_MEM; } } @@ -1091,6 +1094,7 @@ static unsigned long __init e820_type_to_iores_desc(struct e820_entry *entry) case E820_TYPE_NVS: return IORES_DESC_ACPI_NV_STORAGE; case E820_TYPE_PMEM: return IORES_DESC_PERSISTENT_MEMORY; case E820_TYPE_PRAM: return IORES_DESC_PERSISTENT_MEMORY_LEGACY; + case E820_TYPE_MMIO: /* Fall-through: */ case E820_TYPE_RESERVED: return IORES_DESC_RESERVED; case E820_TYPE_SOFT_RESERVED: return IORES_DESC_SOFT_RESERVED; case E820_TYPE_RESERVED_KERN: /* Fall-through: */ @@ -1113,6 +1117,7 @@ static bool __init do_mark_busy(enum e820_type type, struct resource *res) switch (type) { case E820_TYPE_RESERVED: case E820_TYPE_SOFT_RESERVED: + case E820_TYPE_MMIO: case E820_TYPE_PRAM: case E820_TYPE_PMEM: return false; diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 026031b3b782..7987e9c899fa 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -552,6 +552,7 @@ static bool memremap_should_map_decrypted(resource_size_t phys_addr, /* Check if the address is outside kernel usable area */ switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) { case E820_TYPE_RESERVED: + case E820_TYPE_MMIO: case E820_TYPE_ACPI: case E820_TYPE_NVS: case E820_TYPE_UNUSABLE: diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c index 758cbfe55daa..3c19353bae10 100644 --- a/arch/x86/pci/mmconfig-shared.c +++ b/arch/x86/pci/mmconfig-shared.c @@ -425,7 +425,7 @@ static acpi_status find_mboard_resource(acpi_handle handle, u32 lvl, return AE_OK; } -static bool is_acpi_reserved(u64 start, u64 end, enum e820_type not_used) +static bool is_acpi_reserved(u64 start, u64 end) { struct resource mcfg_res; @@ -442,7 +442,14 @@ static bool is_acpi_reserved(u64 start, u64 end, enum e820_type not_used) return mcfg_res.flags; } -typedef bool (*check_reserved_t)(u64 start, u64 end, enum e820_type type); +static bool is_e820_reserved(u64 start, u64 end) +{ + int type = e820__get_entry_type(start, end); + + return type == E820_TYPE_RESERVED || type == E820_TYPE_MMIO; +} + +typedef bool (*check_reserved_t)(u64 start, u64 end); static bool __ref is_mmconf_reserved(check_reserved_t is_reserved, struct pci_mmcfg_region *cfg, @@ -454,7 +461,7 @@ static bool __ref is_mmconf_reserved(check_reserved_t is_reserved, int num_buses; char *method = with_e820 ? "E820" : "ACPI motherboard resources"; - while (!is_reserved(addr, addr + size, E820_TYPE_RESERVED)) { + while (!is_reserved(addr, addr + size)) { size >>= 1; if (size < (16UL<<20)) break; @@ -527,7 +534,7 @@ pci_mmcfg_check_reserved(struct device *dev, struct pci_mmcfg_region *cfg, int e /* Don't try to do this check unless configuration type 1 is available. how about type 2 ?*/ if (raw_pci_ops) - return is_mmconf_reserved(e820__mapped_all, cfg, dev, 1); + return is_mmconf_reserved(is_e820_reserved, cfg, dev, 1); return false; } diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 147c30a81f15..23b361447417 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -173,10 +173,13 @@ static void __init do_add_efi_memmap(void) case EFI_PERSISTENT_MEMORY: e820_type = E820_TYPE_PMEM; break; + case EFI_MEMORY_MAPPED_IO: + e820_type = E820_TYPE_MMIO; + break; default: /* * EFI_RESERVED_TYPE EFI_RUNTIME_SERVICES_CODE - * EFI_RUNTIME_SERVICES_DATA EFI_MEMORY_MAPPED_IO + * EFI_RUNTIME_SERVICES_DATA * EFI_MEMORY_MAPPED_IO_PORT_SPACE EFI_PAL_CODE */ e820_type = E820_TYPE_RESERVED; diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c index 01ddd4502e28..d0795adc2534 100644 --- a/drivers/firmware/efi/libstub/x86-stub.c +++ b/drivers/firmware/efi/libstub/x86-stub.c @@ -470,12 +470,15 @@ setup_e820(struct boot_params *params, struct setup_data *e820ext, u32 e820ext_s case EFI_RESERVED_TYPE: case EFI_RUNTIME_SERVICES_CODE: case EFI_RUNTIME_SERVICES_DATA: - case EFI_MEMORY_MAPPED_IO: case EFI_MEMORY_MAPPED_IO_PORT_SPACE: case EFI_PAL_CODE: e820_type = E820_TYPE_RESERVED; break; + case EFI_MEMORY_MAPPED_IO: + e820_type = E820_TYPE_MMIO; + break; + case EFI_UNUSABLE_MEMORY: e820_type = E820_TYPE_UNUSABLE; break; From patchwork Mon Feb 14 15:17:59 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 542543 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB106C433FE for ; Mon, 14 Feb 2022 15:18:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355744AbiBNPTB (ORCPT ); Mon, 14 Feb 2022 10:19:01 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:45450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355751AbiBNPTA (ORCPT ); Mon, 14 Feb 2022 10:19:00 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4403B5BD24 for ; Mon, 14 Feb 2022 07:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644851931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Qtxii3fDgLz/BjfAaX9vX0zo678hl9XTBNM9+pp5Auk=; b=ifqS2dm4XeI0Dt7lCwcHBP0dVJlfg1CuWCwNC0dEaPRp8yd4eC0B+kc/J/a07/J58iNbE2 tHlGvom/3MqJGH/17koO49TTAfjN0sf9UMHB/pGol3PX3HXLnbgk1DaEtOb+Xylpt7hnOb 1wcw5FIjr/0/9UReGjckU16/tIh4gts= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-499-ywGxEZJ_MfqW6Ba62kVU-A-1; Mon, 14 Feb 2022 10:18:46 -0500 X-MC-Unique: ywGxEZJ_MfqW6Ba62kVU-A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1E9C22F25; Mon, 14 Feb 2022 15:18:44 +0000 (UTC) Received: from x1.localdomain.com (unknown [10.39.192.237]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F2AD2B598; Mon, 14 Feb 2022 15:18:24 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Bjorn Helgaas , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" Cc: Hans de Goede , Mika Westerberg , =?utf-8?q?Krzysztof_Wilc?= =?utf-8?q?zy=C5=84ski?= , Myron Stowe , Juha-Pekka Heikkila , =?utf-8?q?Benoit_Gr?= =?utf-8?q?=C3=A9goire?= , Hui Wang , linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: [RFC 2/2] x86/PCI: Ignore EFI memmap MMIO entries Date: Mon, 14 Feb 2022 16:17:59 +0100 Message-Id: <20220214151759.98267-3-hdegoede@redhat.com> In-Reply-To: <20220214151759.98267-1-hdegoede@redhat.com> References: <20220214151759.98267-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Linux excludes E820 reserved addresses when allocating addresses from the PCI host bridge window. This behavior is needed for at least 2 reasons: 1. Some BIOS-es contain a bug where they add addresses which map to system RAM in the PCI host bridge window returned by the ACPI _CRS method, see commit 4dc2287c1805 ("x86: avoid E820 regions when allocating address space"). 2. At least the Lenovo X1 carbon gen 2 BIOS has an overlap between an E820 reserved range and the ACPI _CRS providing the PCI bridge windows: BIOS-e820: [mem 0x00000000dceff000-0x00000000dfa0ffff] reserved pci_bus 0000:00: root bus resource [mem 0xdfa00000-0xfebfffff window] If Linux assigns the overlapping 0xdfa00000-0xdfa0ffff range to a PCI BAR then the system fails to resume after a suspend. Recently (2019) some systems have shown-up with EFI memmap MMIO entries covering the entire _CRS returned PCI bridge memory window. These memmap entries get converted into e820_table entries, causing all attempts to assign memory to PCI BARs which have not been setup by the BIOS to fail. For example see these dmesg snippets from a Lenovo IdeaPad 3 15IIL 81WE: efi: mem63: [MMIO |RUN| | | | | | | | | | | | |UC] range= [0x0000000065400000-0x00000000cfffffff] (1708MB) [mem 0x000000004bc50000-0x00000000cfffffff] reserved pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window] pci 0000:00:15.0: BAR 0: no space for [mem size 0x00001000 64bit] pci 0000:00:15.0: BAR 0: failed to assign [mem size 0x00001000 64bit] Since the problem is specifically caused by EFI memmap entries with a MMIO type, use the new E820_TYPE_MMIO marking of e820 entries translated from MMIO EFI memmap entries to skip these entries when excluding e820 reservations in arch_remove_reservations(), fixing the problem of not being able to find free space for unassigned BARs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206459 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1868899 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1871793 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2029207 BugLink: https://bugs.launchpad.net/bugs/1878279 BugLink: https://bugs.launchpad.net/bugs/1931715 BugLink: https://bugs.launchpad.net/bugs/1932069 BugLink: https://bugs.launchpad.net/bugs/1921649 Signed-off-by: Hans de Goede --- arch/x86/kernel/resource.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/resource.c b/arch/x86/kernel/resource.c index 9b9fb7882c20..bd501f787a10 100644 --- a/arch/x86/kernel/resource.c +++ b/arch/x86/kernel/resource.c @@ -31,6 +31,10 @@ static void remove_e820_regions(struct resource *avail) for (i = 0; i < e820_table->nr_entries; i++) { entry = &e820_table->entries[i]; + /* Some fw reserves the entire PCI bridge window as MMIO */ + if (entry->type == E820_TYPE_MMIO) + continue; + resource_clip(avail, entry->addr, entry->addr + entry->size - 1); }