Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2345356rwb; Fri, 9 Dec 2022 00:31:45 -0800 (PST) X-Google-Smtp-Source: AA0mqf7HvQ+UgWN0iSc/Zc803OU3DUNfWagE6erOhPbYfM3zR+8xKyfPOVSWK4tcfjPIz0Y0DAXn X-Received: by 2002:aa7:d556:0:b0:45c:835b:7990 with SMTP id u22-20020aa7d556000000b0045c835b7990mr4104087edr.17.1670574705162; Fri, 09 Dec 2022 00:31:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670574705; cv=none; d=google.com; s=arc-20160816; b=nGaZnnyRpx+iLlpf3cTtRmJjgY6mDKF89I+1q7gP/soHwAd/K2MiztPGDGkevMEBek vPfhgk9uJFvpbYvCIqYfxupk8EHnI1L5W2fapt1Vy2VaaivCE1GMLLVpr2YEvEDV+/zg 8eT8Ct+wFd8sfyXI8T6WxbmzkcM0Z+0ZyTwKUNp5pLQXrj3lUEXdbjP4MGf+b2e15UNI e8jsGyIKM5mAj9/rbxfubuGQUrpXRE+stA4kAyBs+a0hEY4t57XGGcR1Sj+B512XsRlT TkvJrUzTZpOHqz4STCXlBqneLKMVNXxoTsBWztvrJtRRwbEFVvqGAoDFrf8GcXjG0Dbe dtJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=V3QgFqyfFrbqLPDlT52YmMXtZ218dmGSv5KKxRxqdCk=; b=DBpeZzb0WpCgYtWsWrPtuj5usP90wbWIFdon4+kI2hqRM6khlUrB7ytZW3Qby0ttqF HYbUOjvjGz3XSl+N3jwnC0Xvxb+ErpCpUXLpNfSx176dQs+gzCeZe5dHsptzftF4ELDl lb9OeZbpW3gC757+AXmgkhoEUaxlLbWiSSt6xhZNqfTQqZWztGrJiM4R5nLYx21onUbN 2nSHAkgGpzPsZpwXxFOJA3SCWkWca0MsJG/ATFUerpLLpk4Lvdos+6Dkh9WrfQXelrOl XjduM8v0SylMTGQwk0NmNu36dM07mWx6l+CgKVpl9OUWbFKHzQ734dUWku5p7JBMDTNu DQaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QTUyOdpv; 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=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i2-20020a05640242c200b0046aa32bdcd7si963273edc.411.2022.12.09.00.31.27; Fri, 09 Dec 2022 00:31:45 -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=@redhat.com header.s=mimecast20190719 header.b=QTUyOdpv; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229936AbiLIIHw (ORCPT + 73 others); Fri, 9 Dec 2022 03:07:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229834AbiLIIHt (ORCPT ); Fri, 9 Dec 2022 03:07:49 -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 ESMTPS id C29CD5B5BA for ; Fri, 9 Dec 2022 00:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670573210; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V3QgFqyfFrbqLPDlT52YmMXtZ218dmGSv5KKxRxqdCk=; b=QTUyOdpvlz+MawvTlUAji5t3giue/gNYhUxHM8ZtJfgROXa6mZmNwNjDPWug23wMXC289U 6xzxSbNAQCrWg6MLbUroCpxCysGN1+JAPJOLAb5TyNUE38OpjYLvMIE9PF2VE5/kBsh1mi smU9KqZurP+4YR9kyA7RvqWQSrDW+IY= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-573-qaghu8TdN0izZjbQINzMTQ-1; Fri, 09 Dec 2022 03:06:48 -0500 X-MC-Unique: qaghu8TdN0izZjbQINzMTQ-1 Received: by mail-ej1-f72.google.com with SMTP id hp16-20020a1709073e1000b007adf5a83df7so2608152ejc.1 for ; Fri, 09 Dec 2022 00:06:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=V3QgFqyfFrbqLPDlT52YmMXtZ218dmGSv5KKxRxqdCk=; b=UrpPYRrEGI9JF4LJcA7IfWMBKkuYaoqKLf8TP5gqoMUaHqglEoEPbPeWEqP8Kvo/jf 4Hzk1ZWUKBmu7kg2sH698Llk+UkofOSF1ErSDXAaw0pg7VHVGkTIJkO/tNi9g/LGiE7J 8XuWv5+L3XAMJjKEaRbFdzVukQlDZoiFSYItPwTZwn4AAAzfjgdemzhI8l2Ssdk7vYLL MXsG4bVTQO8gFa5tfH8zVnSseedFyfodZqWDM/PMOmMc1GiNnTQ7T/kFtfbZ8fxhLh8p aciFEcutaHA0ac9V64eCpIBfjKdgEK6Ksko9GL4IX6oIkbKxu+XEx5MItv87VZACnSIK Dcfw== X-Gm-Message-State: ANoB5plLsiwj7MhHTm2fTnPX0gMu474iwba5UgQMBIsZ96wGa3oWV/K0 wsODr6YA8qXxlKs0UvvXgxaNHIJuhyhI99D/Qq8ah6bQOWqqNYMeXw6h/zE9j3Fg6WpP+YmwrHy 8cFXJnzVuLnd9u6/sBcMsS/Cb X-Received: by 2002:a17:907:cb83:b0:7a7:3f0c:e99b with SMTP id un3-20020a170907cb8300b007a73f0ce99bmr5064393ejc.6.1670573207473; Fri, 09 Dec 2022 00:06:47 -0800 (PST) X-Received: by 2002:a17:907:cb83:b0:7a7:3f0c:e99b with SMTP id un3-20020a170907cb8300b007a73f0ce99bmr5064371ejc.6.1670573207238; Fri, 09 Dec 2022 00:06:47 -0800 (PST) Received: from ?IPV6:2001:1c00:c1e:bf00:d69d:5353:dba5:ee81? (2001-1c00-0c1e-bf00-d69d-5353-dba5-ee81.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:d69d:5353:dba5:ee81]) by smtp.gmail.com with ESMTPSA id lo14-20020a170906fa0e00b007c0d0dad9c6sm263054ejb.108.2022.12.09.00.06.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Dec 2022 00:06:46 -0800 (PST) Message-ID: <805ea628-77a2-a1c1-10fe-edf2203e9c86@redhat.com> Date: Fri, 9 Dec 2022 09:06:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH v2 1/4] efi/x86: Remove EfiMemoryMappedIO from E820 map To: Bjorn Helgaas , linux-pci@vger.kernel.org Cc: Florent DELAHAYE , Konrad J Hambrick , Matt Hansen <2lprbe78@duck.com>, =?UTF-8?Q?Benoit_Gr=c3=a9goire?= , Nicholas Johnson , Mika Westerberg , Werner Sembach , mumblingdrunkard@protonmail.com, linux-kernel@vger.kernel.org, Bjorn Helgaas References: <20221208190341.1560157-1-helgaas@kernel.org> <20221208190341.1560157-2-helgaas@kernel.org> Content-Language: en-US, nl From: Hans de Goede In-Reply-To: <20221208190341.1560157-2-helgaas@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE 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 Hi, One comment (logging bug in patch) below: On 12/8/22 20:03, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > 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 > Tested-by: Konrad J Hambrick > Tested-by: Matt Hansen <2lprbe78@duck.com> > Signed-off-by: Bjorn Helgaas > Cc: Hans de Goede > --- > 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); The logging in this else is re-using the start and end from the previous section which was actually removed. E.g. Matt's latest log from: https://bugzilla.redhat.com/show_bug.cgi?id=1868899 has: [ 0.000000] e820: remove [mem 0xfc800000-0xfe7fffff] reserved [ 0.000000] efi: Not removing mem46: MMIO range=[0xfc800000-0xfe7fffff] (4KB) from e820 map [ 0.000000] efi: Not removing mem47: MMIO range=[0xfc800000-0xfe7fffff] (32KB) from e820 map [ 0.000000] efi: Not removing mem49: MMIO range=[0xfc800000-0xfe7fffff] (8KB) from e820 map [ 0.000000] efi: Not removing mem50: MMIO range=[0xfc800000-0xfe7fffff] (4KB) from e820 map Notice how all the "Not removing ..." lines log the same range as the actually removed map entry above them. Regards, Hans > + } > + } > + 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(); > }