Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4471208rwb; Sun, 4 Dec 2022 02:39:51 -0800 (PST) X-Google-Smtp-Source: AA0mqf6vtqDA70NjnCTJ1XYxcaaRGNkJsBlj/MQ9dsLrnhx/z99GNCpLGTSKGbQNHCowAED5HLgS X-Received: by 2002:a63:1015:0:b0:470:5f22:1496 with SMTP id f21-20020a631015000000b004705f221496mr50828362pgl.585.1670150391201; Sun, 04 Dec 2022 02:39:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670150391; cv=none; d=google.com; s=arc-20160816; b=GoIQQXe+sm9nWpfjqLKYZwoWM9H3VydswaoXXnD8bBkh5vbXB+t1xbCD8frkhljp3u TI9MR1D+X/pPe7vP66bItu76yRpPNdIOm0cxPJPvKeFfwkTQzazwDeZMtOPIDv+uPzVj bazYj0TRm/g4QpzlNvL5J7D/Z/7Vymsr0VjHOOXHRgYsaxuk8py4uuqsO5aARDJ8zGVf TT6zCqI/Ffin5y8e1o+DcMlaITq1EKund+ChOGW+6UOBvQ9oX9XgDuqHNkoKKtMoVtJQ snm47F3lh7Kb4mTXX3D7JsDMXHaw+IZUbvnJZHi2MoiuUksX4vwyNt3D4XGRyrR4FAV7 H5ww== 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 :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=FKzg6vXZ9C5N30cmZGMkFXevDmG/puHgCUnXYbnQxtw=; b=Z0Danuh+dmC6zpByCCsbF200rQIYvJbPv324PxwxSymsaA8nM17PYfudSzgBuacAYv w43cmLUQqrzJnvRWt2U4BE4Pr2UWO/QLK8I1E9b018JxnKijCVgUidVdYTfp4E42FUmF Rx6RkJ4t5M3UQ9yjst9jFvkuU9tbaRD28V95Kv3JZca85DpI/wmH2RmYfoq5ryBsisAh zbgu946REfWpR3Se9XwQyHQOnU0dpUSyfcOXkxP1RXuDwX/RI9Cuu+XX7MpJVj8qPw3g wkmf2TJfqZkndRl2EGXaOIjDrofkQjeyHOQl8Xb9OvgYUQzgwVINV1HfkFmkKgDkJJOO y9Pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LLUd8ow7; 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 x1-20020a1709029a4100b00184c33ddeb8si10788844plv.23.2022.12.04.02.39.40; Sun, 04 Dec 2022 02:39:51 -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=LLUd8ow7; 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 S229954AbiLDJaR (ORCPT + 83 others); Sun, 4 Dec 2022 04:30:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229560AbiLDJaP (ORCPT ); Sun, 4 Dec 2022 04:30:15 -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 4057812D1F for ; Sun, 4 Dec 2022 01:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670146160; 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=FKzg6vXZ9C5N30cmZGMkFXevDmG/puHgCUnXYbnQxtw=; b=LLUd8ow7w1Z2PMGYXausxOeWyAhKSR8lTSf8nd2ofKPq+FULEvWkgDPILf23kJyOHjdnb6 Er7RML5GR7obXb1IIzPtNZ51MvG3z+lrAPLvTUBOvCqJBaQYx3F5e4WBZK2wJaP2lU5aL2 m7EC+QLxL4m/eQD3aueyHfi6V+++cjE= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-307-UlR5zDlAOGGTv_Hb9JqpXA-1; Sun, 04 Dec 2022 04:29:19 -0500 X-MC-Unique: UlR5zDlAOGGTv_Hb9JqpXA-1 Received: by mail-ed1-f69.google.com with SMTP id i2-20020a05640242c200b0046c66305ebaso947030edc.15 for ; Sun, 04 Dec 2022 01:29:18 -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:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FKzg6vXZ9C5N30cmZGMkFXevDmG/puHgCUnXYbnQxtw=; b=AJksQlM9liZWv0wQaLH5Soccy5WHfhUIf5OdKQy/SDyCaFREHeKUyKqW9QyJIDALIV LxXtvlq/irt+oN9VX8IuNVpwIPgWEEnY8DTuDg82ld1NiqtFYnI45V49HoDookTt2479 W9lrGWT6nLARD+m3F8hDjs694pw/W76TEuk6aV2Aj2z5h2CLTlnicTI/WeLRmnH0F6ln WbYQmhoHK7X7SAiHMTEzy15vO16Nwdsj56s2Q9GeeR1pzuRkmaLCQTKeECfOdUkLybWr 8hSJa9uNuYLngBMr+og4/w7joDzA0smE1UsXixlkN+5EP5IAHIwyDnflNcft6eHRl6cS TpMg== X-Gm-Message-State: ANoB5pkDYlsM4xkI0V/zCnfm52OwISa5SdLYUlhFbV0IaMJANdrqQOU3 1XJmEflcjKzHFUUwvXcc6fD2GpcUjS1PjFXi4tnjDvU6F9zhkRz50QYjVlr6MoADkMJhQcbMeOi VacufZ6Z2zp8r/ApiP4V6TFu8 X-Received: by 2002:a17:906:49c4:b0:7c0:d23c:ead5 with SMTP id w4-20020a17090649c400b007c0d23cead5mr5686043ejv.606.1670146157889; Sun, 04 Dec 2022 01:29:17 -0800 (PST) X-Received: by 2002:a17:906:49c4:b0:7c0:d23c:ead5 with SMTP id w4-20020a17090649c400b007c0d23cead5mr5686032ejv.606.1670146157696; Sun, 04 Dec 2022 01:29:17 -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 cn7-20020a0564020ca700b0045ce419ecffsm4970915edb.58.2022.12.04.01.29.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Dec 2022 01:29:17 -0800 (PST) Message-ID: Date: Sun, 4 Dec 2022 10:29:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH 0/4] PCI: Continue E820 vs host bridge window saga Content-Language: en-US, nl To: Bjorn Helgaas Cc: linux-pci@vger.kernel.org, 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: <20221203175743.GA1121812@bhelgaas> From: Hans de Goede In-Reply-To: <20221203175743.GA1121812@bhelgaas> 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=unavailable 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 Bjorn, On 12/3/22 18:57, Bjorn Helgaas wrote: > On Sat, Dec 03, 2022 at 01:44:10PM +0100, Hans de Goede wrote: >> Hi Bjorn, >> >> On 12/2/22 22:18, Bjorn Helgaas wrote: >>> 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. >> >> Thank you for working on this. I'm a bit worried about this series though. >> >> The 2 things which I worry about are: >> >> >> 1. I think this will not help when people boot in BIOS (CSM) mode rather >> then UEFI mode which quite a few Linux users still do because they learned >> to do this years ago when Linux EFI support (and EFI fw itself) was still >> a bit in flux. >> >> IIRC from the last time we looked at this in CSM mode the BIOS itself >> translates the EfiMemoryMappedIO areas to reserved E820 regions. So when >> people use the BIOS CSM mode to boot, then this patch will not help >> since the kernel lacks the info to do the translation. > > Right, if BIOS CSM puts EfiMemoryMappedIO in the E820 map the same way > bootloaders do, and the kernel doesn't have the EFI memory map, this > series won't help. So I just got the requested dmesg in BIOS CSM mode from: https://bugzilla.redhat.com/show_bug.cgi?id=1868899 And it says: [ 0.000000] BIOS-e820: [mem 0x000000004bc50000-0x00000000cfffffff] reserved [ 0.316140] pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window] So I'm afraid that I remembered correctly and the CSM adds the EfiMemoryMappedIO regions to the E820 map as reserved :( So as you said, this series won't help for people booting in BIOS compatibility mode. Which means that we should at least keep the current list of no_e820 quirks to avoid regressing those models when booted in BIOS compatibility mode. And maybe still add at least the Clevo model for which I recently submitted a new no_e820 quirk so that that will work in BIOS CSM mode too ? Note I know you did not propose to drop the quirks in this series, just covering all the bases here. Regards, Hans