From patchwork Fri Dec 2 21:18:34 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 2555 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1075770wrr; Fri, 2 Dec 2022 13:21:42 -0800 (PST) X-Google-Smtp-Source: AA0mqf44V62HMmxGrIiIyJkX8FC3FfOlzPQjDC16gdCdN66US2B/auIf7n/+JgE/GCs2MObIYIh+ X-Received: by 2002:a17:906:1146:b0:78d:9f02:5458 with SMTP id i6-20020a170906114600b0078d9f025458mr47673609eja.753.1670016101819; Fri, 02 Dec 2022 13:21:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670016101; cv=none; d=google.com; s=arc-20160816; b=ADEPI6tTE/Ke8D4b6dLG9wMc4Fd704eR17g8ZqhIe7oG1Ve3zDlqPjP9FAPcNYlb6C 1Tav/ya//Z7kReM50tuuZ4PKW0Jbvug8/wBEcQfkzUn+g6ccgNtLkeNl3spPt85M5Hlf drOPwEEcLOdxdx9/4LIQbm8BGu0G8+3KdOaqHMIriEGNeD6IopWFAen5zcqZIMAvLG8+ lprR5vZigBPfKGeEIdXPQdSszYVyUhYHNzi5C+7qzbKTKyNXzWN24b3ClOmOOFKpm4yM TkTanPWasaChlhn6AmKwCVvvRWjpOP9HYBcJvc9/U2nrVxR6MusJIe0eKZYITT1xAp95 mXcw== 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=z2FOPD1rxFRPinJIz3a/USpiAAMYHK1mmTzHNT25Beg=; b=kb3GRdlD/Y3sng9R+E972n0AtBw2vbtpp7zeMRu6LvgGHmjOl9jQWX/yuoMlYztZ8Y WYYDoQ7G9XXLArzQS+xwIa+iP34oUdTtCrpFuaeXWvBSQfNE3FfUucqRdFsrYXQrvXaZ 47TRQciD9yVeR+flH/Tx0kzu0HJsPho9XWqDXWM9oVW0mCe2HLMMhNnKFH9xmc/FB6tk ImJlpbVdH9PiuFyR+k5hZ+4izTbGz9KX5AOtz6RBemfh/WiTxeac2ldZHPSuCx4FPiNI 9jbc7+J9pLn97ygBqTf0Fsqm3ye/LtcrD+6rQfdfkl4MS4Gu32IiFO8niT0vErqyb7e+ OLnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="d4qTFc/f"; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sc38-20020a1709078a2600b007ade20fc40csi6775036ejc.810.2022.12.02.13.21.17; Fri, 02 Dec 2022 13:21:41 -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="d4qTFc/f"; 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 S234480AbiLBVTE (ORCPT + 99 others); Fri, 2 Dec 2022 16:19:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234242AbiLBVSv (ORCPT ); Fri, 2 Dec 2022 16:18:51 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 867F65915A; Fri, 2 Dec 2022 13:18:46 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 900C8623D6; Fri, 2 Dec 2022 21:18:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDA10C433D6; Fri, 2 Dec 2022 21:18:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670015925; bh=2rrX47NWa70VI8AqxvMAoJDdj+in56xV4jYSGcyJcbo=; h=From:To:Cc:Subject:Date:From; b=d4qTFc/f72OMYxi/1HZE0CdQFKVlgLXIQsf6tAbNbpLXfL/lJBiriy9Skujf59U/l UTDzQnx5ZAY1+ZeCHAeTueZVZwJG3MpPXzmAnjFtm+rxxzsWuPtng1ikgX6s9D1U9k 7tk1HQdZIhZCURQkfR9xlVfsZ1IxOZXND7fKXaLauWlAtasxRdI0t762JdMwYay7Mv SYxaVcGFm9XnsMlsPSCdH59mEBmngBdsR2ynwvKt3bV6FQI6t+PVDg7NmhkA0VveWW 3tzTlcIsad84rsaDJJd9vI4bQ+Wwa+xJHXHXiqGi+V6pauXAyoXc4qTuK4jI8VPOf8 Sz/xgLOG0MGig== 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_Gr=C3=A9goire?= , Nicholas Johnson , Mika Westerberg , Werner Sembach , mumblingdrunkard@protonmail.com, linux-kernel@vger.kernel.org, Bjorn Helgaas Subject: [PATCH 0/4] PCI: Continue E820 vs host bridge window saga Date: Fri, 2 Dec 2022 15:18:34 -0600 Message-Id: <20221202211838.1061278-1-helgaas@kernel.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751138803621454594?= X-GMAIL-MSGID: =?utf-8?q?1751138803621454594?= 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 any 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. 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 | 7 +++++-- arch/x86/pci/acpi.c | 2 +- arch/x86/platform/efi/efi.c | 36 ++++++++++++++++++++++++++++++++++++ drivers/pci/bus.c | 4 ++++ 4 files changed, 46 insertions(+), 3 deletions(-)