Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp397007rdb; Tue, 5 Dec 2023 08:18:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IEyncqu1svUBcwi02UzPqL7Xvfrd8CNCqDEKm73COXTLnqKYqD9azIQEgdNtKYe1TwwVflk X-Received: by 2002:a17:90a:ec08:b0:286:40e7:e99 with SMTP id l8-20020a17090aec0800b0028640e70e99mr1190985pjy.28.1701793088573; Tue, 05 Dec 2023 08:18:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701793088; cv=none; d=google.com; s=arc-20160816; b=qEHJMA9Z7xyCZhTorjH3FvzNyV9pJFeKzaPr8vc0Da1FSi20ER+QE+OJNf5HyLmf63 dx5zt+ObBR9PU2YKrud7NL58qHKjzAL9qeUw4RJgIWW8oOTIPs4+5fv+CfmDPyjZ1KX7 OJnINYGb3B9QPll7im6vszWqzZzLDRCE3JRrygMAv7SERVMXS9+lBlDZHfKPC6vBSACT OiWnqRmQBiTjeCong+jkYnz+WSWz2D6rVE3cVqBbKZ4DjICoLLkqQ156cZFl8/gkemoS xK5n5hHVx0b4CVNRvq8lN5o1ANHWKK5BSGVYEhOhvFagh0cGseZ1zZxHrTCtYe1CzoJo 0o+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=aSwscfjJKMVf60U8qklwWq5jFQsA8A9uujIf5UJuz1M=; fh=Ss+gMWPWhxa5A6H0Pmo/zSgzPxOFo1vKyAsFQX+gdw0=; b=JCyXfKxCLMt4e5SxMK9Hggll1wzB7N+t0UrKZYl78Bt1eIT/fvwRXjmfWgemPDykuz wRudxKNl0NiaR+Oa7pwsuXspVq61TVsqx14wnxSTJEcts+pWGqsE3NRY8FtGJuSH6uuu 3/CvJuK7CEXJdIr3eyQlIN0KioaO1dBp05jHYc077VEH1phJGlxyqiNbTMqggvCObUs6 YM8lVxomWMJJhuycXaT1zvQhChao+HOmSaOf1HURtt6GLYia8yiF+65zPPxPeLt+NaJd /Bt0t6g/5GJ4hextPQRdXJajW0H5UHbS2p6U9QqQhsNw0BrVbhcFzT6/cKlJlO5O/TF6 BIlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mcuDl8jI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 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 pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id p12-20020a17090ab90c00b00286fb295e6fsi170103pjr.166.2023.12.05.08.18.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 08:18:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mcuDl8jI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 3B8B9805914F; Tue, 5 Dec 2023 08:17:27 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231888AbjLEQRJ (ORCPT + 99 others); Tue, 5 Dec 2023 11:17:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60058 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229550AbjLEQRJ (ORCPT ); Tue, 5 Dec 2023 11:17:09 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80A089E for ; Tue, 5 Dec 2023 08:17:15 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECC70C43397; Tue, 5 Dec 2023 16:17:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701793035; bh=z37uNL6IIU4NauPVaUDXZWwyCByspD3QAo4UgtuVbOI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=mcuDl8jI+PwKHmlQ9yZ/pc0f4DAqmj5xvmsYiC6++IzGyRxVSHRQzH4xa0CPA+8Iy 1jvmwXwkKKQAjz0R9Nmha+2/D+c4QzcmOJ7yRQRt4Mqlrq4tMmAw62TFU2xt0xuB75 CNPZfZMhcE8injQ3wiR+ZniXn81CY+G3ldXqJffuBW+u3iMK8x9xdn+4bgUdapCpyz U4UxrIpjiLgNatf2fRO0R97oJE+jVqj/hCJik0N96zr7F0ZdczlUtrgmVzUFmo+d5a BbBM+QLHbp5KGMGC4WWaobp8wWC2YvdRtvAiZaKDyhJbX/DzXdNO/iknl9slYlFoJk WAIdNKyVhJhvg== Date: Tue, 5 Dec 2023 10:17:13 -0600 From: Bjorn Helgaas To: Mario Limonciello Cc: Bjorn Helgaas , "Rafael J . Wysocki" , linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/pci: Stop requiring MMCONFIG to be declared in E820, ACPI or EFI for newer systems Message-ID: <20231205161713.GA674824@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231205154845.44463-1-mario.limonciello@amd.com> X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 05 Dec 2023 08:17:27 -0800 (PST) On Tue, Dec 05, 2023 at 09:48:45AM -0600, Mario Limonciello wrote: > commit 7752d5cfe3d1 ("x86: validate against acpi motherboard resources") > introduced checks for ensuring that MCFG table also has memory region > reservations to ensure no conflicts were introduced from a buggy BIOS. > > This has proceeded over time to add other types of reservation checks > for ACPI PNP resources and EFI MMIO memory type. The PCI firmware spec > however says that these checks are only required when the operating system > doesn't comprehend the firmware region: > > ``` > If the operating system does not natively comprehend reserving the MMCFG > region, the MMCFG region must be reserved by firmware. The address range > reported in the MCFG table or by _CBA method (see Section 4.1.3) must be > reserved by declaring a motherboard resource. For most systems, the > motherboard resource would appear at the root of the ACPI namespace > (under \_SB) in a node with a _HID of EISAID (PNP0C02), and the resources > in this case should not be claimed in the root PCI bus’s _CRS. The > resources can optionally be returned in Int15 E820h or EFIGetMemoryMap > as reserved memory but must always be reported through ACPI as a > motherboard resource. > ``` My understanding is that native comprehension would mean Linux knows how to discover and/or configure the MMCFG base address and size in the hardware and that Linux would then reserve that region so it's not used for anything else. Linux doesn't have that, at least for x86. It relies on the MCFG table to discover the MMCFG region, and it relies on PNP0C02 _CRS to reserve it. > Running this check causes problems with accessing extended PCI > configuration space on OEM laptops that don't specify the region in PNP > resources or in the EFI memory map. That later manifests as problems with > dGPU and accessing resizable BAR. Is there a problem report we can reference here? Does the problem still occur with this series? https://lore.kernel.org/r/20231121183643.249006-1-helgaas@kernel.org This appeared in linux-next 20231130. > Similar problems don't exist in Windows 11 with exact same > laptop/firmware stack, and in discussion with AMD's BIOS team > Windows doesn't have similar checks. I would love to know AMD BIOS team's take on this. Does the BIOS reserve the MMCFG space in any way? > As this series of checks was first introduced as a mitigation for buggy > BIOS before EFI was introduced add a BIOS date range to only enforce the > checks on hardware that predates the release of Windows 11. Many of the MMCFG checks in Linux are historical artifacts that are likely related to Linux defects, not BIOS defects, so I wouldn't expect to see them in Windows. But it's hard to remove them now. > Link: https://members.pcisig.com/wg/PCI-SIG/document/15350 > PCI Firmware Specification 3.3 > Section 4.1.2 MCFG Table Description Note 2 > Signed-off-by: Mario Limonciello > --- > arch/x86/pci/mmconfig-shared.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c > index 4b3efaa82ab7..e4594b181ebf 100644 > --- a/arch/x86/pci/mmconfig-shared.c > +++ b/arch/x86/pci/mmconfig-shared.c > @@ -570,9 +570,13 @@ static void __init pci_mmcfg_reject_broken(int early) > > list_for_each_entry(cfg, &pci_mmcfg_list, list) { > if (pci_mmcfg_check_reserved(NULL, cfg, early) == 0) { > - pr_info(PREFIX "not using MMCONFIG\n"); > - free_all_mmcfg(); > - return; > + if (dmi_get_bios_year() >= 2021) { > + pr_info(PREFIX "MMCONFIG wasn't reserved by ACPI or EFI\n"); I think this leads to using the MMCONFIG area without reserving it anywhere, so we may end up assigning that space to something else, which won't work, i.e., the problem described here: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?id=5cef3014e02d > + } else { > + pr_info(PREFIX "not using MMCONFIG\n"); > + free_all_mmcfg(); > + return; > + } > } > } > } > -- > 2.34.1 >