On Sat, May 07, 2022 at 12:09:03PM +0200, Hans de Goede wrote:
> Hi Bjorn,
>
> On 5/6/22 18:51, Bjorn Helgaas wrote:
> > On Thu, May 05, 2022 at 05:20:16PM +0200, Hans de Goede wrote:
> >> Some BIOS-es contain bugs where they add addresses which are already
> >> used in some other manner to the PCI host bridge window returned by
> >> the ACPI _CRS method. To avoid this Linux by default excludes
> >> E820 reservations when allocating addresses since 2010, see:
> >> commit 4dc2287c1805 ("x86: avoid E820 regions when allocating address
> >> space").
> >>
> >> Recently (2019) some systems have shown-up with E820 reservations which
> >> cover the entire _CRS returned PCI bridge memory window, causing all
> >> attempts to assign memory to PCI BARs which have not been setup by the
> >> BIOS to fail. For example here are the relevant dmesg bits from a
> >> Lenovo IdeaPad 3 15IIL 81WE:
> >>
> >> [mem 0x000000004bc50000-0x00000000cfffffff] reserved
> >> pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window]
> >>
> >> The ACPI specifications appear to allow this new behavior:
> >>
> >> The relationship between E820 and ACPI _CRS is not really very clear.
> >> ACPI v6.3, sec 15, table 15-374, says AddressRangeReserved means:
> >>
> >> This range of addresses is in use or reserved by the system and is
> >> not to be included in the allocatable memory pool of the operating
> >> system's memory manager.
> >>
> >> and it may be used when:
> >>
> >> The address range is in use by a memory-mapped system device.
> >>
> >> Furthermore, sec 15.2 says:
> >>
> >> Address ranges defined for baseboard memory-mapped I/O devices, such
> >> as APICs, are returned as reserved.
> >>
> >> A PCI host bridge qualifies as a baseboard memory-mapped I/O device,
> >> and its apertures are in use and certainly should not be included in
> >> the general allocatable pool, so the fact that some BIOS-es reports
> >> the PCI aperture as "reserved" in E820 doesn't seem like a BIOS bug.
> >>
> >> So it seems that the excluding of E820 reserved addresses is a mistake.
> >>
> >> Ideally Linux would fully stop excluding E820 reserved addresses,
> >> but then various old systems will regress.
> >> Instead keep the old behavior for old systems, while ignoring
> >> the E820 reservations for any systems from now on.
> >>
> >> Old systems are defined here as BIOS year < 2018, this was chosen to
> >> make sure that pci_use_e820 will not be set on the currently affected
> >> systems, the oldest known one is from 2019.
> >>
> >> Testing has shown that some newer systems also have a bad _CRS return.
> >> The pci_crs_quirks DMI table is used to keep excluding E820 reservations
> >> from the bridge window on these systems.
> >>
> >> Also add pci=no_e820 and pci=use_e820 options to allow overriding
> >> the BIOS year + DMI matching logic.
> >>
> >> 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://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
> >> Cc: Benoit Grégoire <benoitg@xxxxxxxx>
> >> Cc: Hui Wang <hui.wang@xxxxxxxxxxxxx>
> >> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> >
> >> + * Ideally Linux would fully stop using E820 reservations, but then
> >> + * various old systems will regress. Instead keep the old behavior for
> >> + * old systems + known to be broken newer systems in pci_crs_quirks.
> >> + */
> >> + if (year >= 0 && year < 2018)
> >> + pci_use_e820 = true;
> >
> > How did you pick 2018? Prior to this patch, we used E820 reservations
> > for all machines. This patch would change that for 2019-2022
> > machines, so there's a risk of breaking some of them.
>
> Correct. I picked 2018 because the first devices where using E820
> reservations are causing issues (i2c controller not getting resources
> leading to non working touchpad / thunderbolt hotplug issues) have
> BIOS dates starting in 2019. I added a year margin, so we could make
> this 2019.
>
> > I'm hesitant about changing the behavior for machines already in the
> > field because if they were tested at all with Linux, it was without
> > this patch. So I would lean toward preserving the current behavior
> > for BIOS year < 2023.
>
> I see, I presume the idea is to then use DMI to disable E820 clipping
> on current devices where this is known to cause problems ?
>
> So for v8 I would:
>
> 1. Change the cut-off check to < 2023
> 2. Drop the DMI quirks I added for models which are known to need E820
> clipping hit by the < 2018 check
> 3. Add DMI quirks for models for which it is known that we must _not_
> do E820 clipping
>
> Is this the direction you want to go / does that sound right?
Yes, I think that's what we should do. All the machines in the field
will be unaffected, except that we add quirks for known problems.
Bjorn
