[prev in list] [next in list] [prev in thread] [next in thread]
List: linuxbios
Subject: [coreboot] Re: Fwd: Issues with ACPI _CRS and E820 memory map
From: Tim Wawrzynczak via coreboot <coreboot () coreboot ! org>
Date: 2022-08-25 17:06:50
Message-ID: CAGVHcdrn95pejBfyeM7s_SbaOXJzQX9Sku+9WxaVu=zaK_C65Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Right, I was hoping for some way to have this happen "automatically" so
mistakes can't creep in down the road.
Let me summarize the summary: the issue is that Linux is evaluating _CRS
for PNP0A08 devices
(and presumably others) and then removing e820 reserved regions from
anything that is
advertised in _CRS. This is a workaround Linux has kept for years to deal
with boot firmware
that includes both host bridge registers and windows into PCI memory space
in _CRS; this
is the workaround that is planned to be removed in 2023.
On Mon, Aug 22, 2022 at 7:46 PM Lance Zhao <lance.zhao@gmail.com> wrote:
> We will need to define the "hidden" entry in host _crs to be match with
> E820 "reserved" entry? They may cause some manual work, maybe we can have
> some code change to make it automatically?
>
>
> Tim Wawrzynczak via coreboot <coreboot@coreboot.org> 于2022年8月23日周二
> 04:27写道：
>
>> Hello fellow coreboot folks,
>>
>> I recently received this message from some associates in the Linux kernel
>> community which describes
>> a bug in coreboot firmware for many Intel boards. The gist of it related
>> to inconsistencies between the
>> hostbridge's _CRS method in ACPI and the E820 table (although technically
>> generated by the payload,
>> the e820 table is generally, AFAIK, converted straight from the
>> LB_TAG_MEMORY entry
>> in the coreboot table by most payloads).
>>
>> I have some thoughts on how to address this, but I would like to hear the
>> community's thoughts first.
>>
>> Thanks,
>> -Tim
>>
>> ---------- Forwarded message ---------
>> From: Bjorn Helgaas <helgaas@kernel.org>
>> Date: Thu, Aug 11, 2022 at 12:30 PM
>> Subject: Issues with ACPI _CRS and E820 memory map
>> To: <linux-pci@vger.kernel.org>
>> Cc: Hans de Goede <hdegoede@redhat.com>, Myron Stowe <mstowe@redhat.com>,
>> Kai-Heng Feng <kai.heng.feng@canonical.com>, Andy Shevchenko <
>> andriy.shevchenko@linux.intel.com>, <linux-acpi@vger.kernel.org>, <
>> linux-kernel@vger.kernel.org>
>>
>>
>> This is a heads-up about what I think is a firmware defect in the way
>> some platforms build _CRS methods. We've had a Linux workaround for
>> several years, but the workaround breaks some new machines, so the
>> workaround will be disabled for 2023 and newer machines.
>>
>> Machines that depend on the workaround include:
>>
>> - Dell Precision T3500
>> - Lenovo ThinkPad X1 Gen 2
>> - Asus C523NA (Coral) Chromebook
>> - Likely any machine using coreboot firmware
>>
>> The current versions of the machines above work fine, but 2023
>> versions with similar firmware are likely to break unless the firmware
>> changes. Please forward this to any firmware folks who may be able to
>> help with this issue.
>>
>> Bjorn
>>
>>
>> SUMMARY
>>
>> A Linux change will break future platforms that rely on the E820 memory
>> map to exclude portions of the PCI host bridge windows reported by ACPI
>> _CRS methods.
>>
>> Linux discovers PCI host bridge MMIO windows by evaluating the _CRS
>> method of the ACPI PNP0A03 device that describes the host bridge. It
>> uses these windows to assign address space to PCI BARs.
>>
>> In some cases these _CRS methods are incomplete or incorrect, and it's
>> hard for an OS to work around this.
>>
>> Below are examples of typical problems with _CRS methods.
>>
>> PLATFORMS REPORT NON-WINDOW SPACE VIA _CRS
>>
>> Sometimes _CRS includes host bridge register space or space assigned to
>> hidden PCI devices that are not enumerable by the OS. When an OS
>> assigns
>> this space to PCI devices, it may cause conflicts or devices may not
>> work. This appears to be a firmware defect.
>>
>> Many platforms report this non-window space as "reserved" in the E820
>> memory map, and since 2010, Linux has worked around the _CRS defect by
>> excluding these E820 "reserved" regions from the host bridge MMIO
>> windows [4].
>>
>> Example 1:
>>
>> _CRS includes space that's not usable for PCI devices [1]:
>>
>> E820: [mem 0xdceff000-0xdfa0ffff] reserved
>> PNP0A08 _CRS: [mem 0xdfa00000-0xfebfffff]
>>
>> Note that [mem 0xdfa00000-0xdfa0ffff] is included in both the E820
>> entry and _CRS.
>>
>> If Linux assigns [mem 0xdfa00000-0xdfbfffff] to a PCI device, the
>> system doesn't resume correctly from suspend. If Linux avoids the
>> [mem 0xdfa00000-0xdfa0ffff] area and instead assigns
>> [mem 0xdfb00000-0xdfcfffff], resume works correctly.
>>
>> Example 2:
>>
>> _CRS includes space assigned to a "hidden" PCI device [2, 5]:
>>
>> PCI: 00:0d.0 10 base d0000000 limit d0ffffff mem (fixed) # BIOS log
>>
>> E820: [mem 0xd0000000-0xd0ffffff]
>> PNP0A08 _CRS: [mem 0x80000000-0xe0000000]
>>
>> The 00:0d.0 device is assigned the [mem 0xd0000000-0xd0ffffff] space,
>> but the device is hidden so the OS cannot enumerate it, so the OS
>> doesn't know what space the device consumes.
>>
>> PLATFORMS SUPPLY E820 ENTRIES COVERING ENTIRE _CRS WINDOWS
>>
>> Some recent platforms supply E820 "reserved" regions that cover entire
>> PCI host bridge windows. If Linux excludes these E820 regions from the
>> windows, it cannot assign space to PCI BARs, which means hot-added
>> devices don't work.
>>
>> Example 3:
>>
>> E820 has a "reserved" region that completely covers the 32-bit MMIO
>> window from _CRS [3]:
>>
>> E820: [mem 0x4bc50000-0xcfffffff] reserved
>> PNP0A08 _CRS: [mem 0x65400000-0xbfffffff]
>>
>> Historically, Linux has avoided putting PCI devices in E820 reserved
>> regions to avoid the problems in examples 1 and 2. Avoiding those
>> regions in this case means Linux can't assign space for hot-added
>> devices, so they don't work.
>>
>> LINUX PLANS
>>
>> As far as I know, the ACPI spec does not require an OS to exclude space
>> from _CRS resources based on the E820 memory map, and these conflicting
>> requirements make it impractical for Linux to do so.
>>
>> The "avoid E820 regions" workaround worked for several years, but it no
>> longer works because of platforms that advertise E820 regions that cover
>> *entire* _CRS windows.
>>
>> We plan to make Linux stop excluding E820 regions from _CRS resources
>> for
>> platforms with a BIOS date of 2023 or newer, so new platforms or new
>> BIOS
>> releases that rely on excluding E820 regions may break [6].
>>
>> Linux is likely to be broken on future versions of these platforms
>> unless
>> the firmware updates _CRS methods.
>>
>> If these platforms do not update _CRS methods to be complete and
>> accurate, Linux may not boot. The user's options are to:
>>
>> - Manually boot with a kernel command line option like "pci=use_e820".
>>
>> - Wait for an updated kernel with a platform-specific workaround.
>>
>> WHY DOESN'T THIS AFFECT MICROSOFT WINDOWS?
>>
>> Short answer: I suspect it *does*, but it's less likely to be a problem
>> on Windows.
>>
>> As far as I know, Windows does not exclude MMIO space from _CRS based on
>> the E820 memory map. But Windows allocates PCI BARs from the top down,
>> while Linux allocates from the bottom up. Most of the issues happen
>> with
>> space at the bottom of the _CRS MMIO windows, so Linux is more likely to
>> trip over them than Windows is.
>>
>> REFERENCES
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2029207
>> [2]
>> https://lore.kernel.org/linux-pci/4e9fca2f-0af1-3684-6c97-4c35befd5019@redhat.com/#t
>> [3] https://bugzilla.kernel.org/show_bug.cgi?id=206459
>> [4] https://bugzilla.kernel.org/show_bug.cgi?id=16228
>> [5]
>> https://review.coreboot.org/plugins/gitiles/coreboot/+/dbcf7b16219d%5E%21/
>> [6] https://git.kernel.org/linus/0ae084d5a674
>> _______________________________________________
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-leave@coreboot.org
>>
>
[Attachment #5 (text/html)]
<div dir="ltr">Right, I was hoping for some way to have this happen \
"automatically" so mistakes can't creep in down the \
road.<div><br></div><div>Let me summarize the summary: the issue is that Linux is \
evaluating _CRS for PNP0A08 devices </div><div>(and presumably others) and then \
removing e820 reserved regions from anything that is</div><div>advertised in _CRS. \
This is a workaround Linux has kept for years to deal with boot \
firmware</div><div>that includes both host bridge registers and windows into PCI \
memory space in _CRS; this</div><div>is the workaround that is planned to be removed \
in 2023. </div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Mon, Aug 22, 2022 at 7:46 PM Lance Zhao <<a \
href="mailto:lance.zhao@gmail.com">lance.zhao@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We will \
need to define the "hidden" entry in host _crs to be match with E820 \
"reserved" entry? They may cause some manual work, maybe we can have some \
code change to make it automatically?<div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">Tim Wawrzynczak via coreboot \
<<a href="mailto:coreboot@coreboot.org" \
target="_blank">coreboot@coreboot.org</a>> 于2022年8月23日周二 \
04:27写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div>Hello fellow coreboot folks,</div><div><br></div><div>I recently \
received this message from some associates in the Linux kernel community which \
describes</div><div>a bug in coreboot firmware for many Intel boards. The gist of it \
related to inconsistencies between the </div><div>hostbridge's _CRS method in \
ACPI and the E820 table (although technically generated by the payload,</div><div>the \
e820 table is generally, AFAIK, converted straight from the LB_TAG_MEMORY \
entry</div><div>in the coreboot table by most payloads).</div><div><br></div><div>I \
have some thoughts on how to address this, but I would like to hear the \
community's thoughts first.</div><div><br></div><div>Thanks,</div><div> \
-Tim</div><div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">---------- Forwarded message ---------<br>From: <strong \
class="gmail_sendername" dir="auto">Bjorn Helgaas</strong> <span dir="auto"><<a \
href="mailto:helgaas@kernel.org" \
target="_blank">helgaas@kernel.org</a>></span><br>Date: Thu, Aug 11, 2022 at 12:30 \
PM<br>Subject: Issues with ACPI _CRS and E820 memory map<br>To: <<a \
href="mailto:linux-pci@vger.kernel.org" \
target="_blank">linux-pci@vger.kernel.org</a>><br>Cc: Hans de Goede <<a \
href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>>, Myron \
Stowe <<a href="mailto:mstowe@redhat.com" \
target="_blank">mstowe@redhat.com</a>>, Kai-Heng Feng <<a \
href="mailto:kai.heng.feng@canonical.com" \
target="_blank">kai.heng.feng@canonical.com</a>>, Andy Shevchenko <<a \
href="mailto:andriy.shevchenko@linux.intel.com" \
target="_blank">andriy.shevchenko@linux.intel.com</a>>, <<a \
href="mailto:linux-acpi@vger.kernel.org" \
target="_blank">linux-acpi@vger.kernel.org</a>>, <<a \
href="mailto:linux-kernel@vger.kernel.org" \
target="_blank">linux-kernel@vger.kernel.org</a>><br></div><br><br>This is a \
heads-up about what I think is a firmware defect in the way<br> some platforms build \
_CRS methods. We've had a Linux workaround for<br> several years, but the \
workaround breaks some new machines, so the<br> workaround will be disabled for 2023 \
and newer machines.<br> <br>
Machines that depend on the workaround include:<br>
<br>
- Dell Precision T3500<br>
- Lenovo ThinkPad X1 Gen 2<br>
- Asus C523NA (Coral) Chromebook<br>
- Likely any machine using coreboot firmware<br>
<br>
The current versions of the machines above work fine, but 2023<br>
versions with similar firmware are likely to break unless the firmware<br>
changes. Please forward this to any firmware folks who may be able to<br>
help with this issue. <br>
<br>
Bjorn<br>
<br>
<br>
SUMMARY<br>
<br>
A Linux change will break future platforms that rely on the E820 memory<br>
map to exclude portions of the PCI host bridge windows reported by ACPI<br>
_CRS methods.<br>
<br>
Linux discovers PCI host bridge MMIO windows by evaluating the _CRS<br>
method of the ACPI PNP0A03 device that describes the host bridge. It<br>
uses these windows to assign address space to PCI BARs.<br>
<br>
In some cases these _CRS methods are incomplete or incorrect, and it's<br>
hard for an OS to work around this.<br>
<br>
Below are examples of typical problems with _CRS methods.<br>
<br>
PLATFORMS REPORT NON-WINDOW SPACE VIA _CRS<br>
<br>
Sometimes _CRS includes host bridge register space or space assigned to<br>
hidden PCI devices that are not enumerable by the OS. When an OS assigns<br>
this space to PCI devices, it may cause conflicts or devices may not<br>
work. This appears to be a firmware defect.<br>
<br>
Many platforms report this non-window space as "reserved" in the \
E820<br> memory map, and since 2010, Linux has worked around the _CRS defect by<br>
excluding these E820 "reserved" regions from the host bridge MMIO<br>
windows [4].<br>
<br>
Example 1:<br>
<br>
_CRS includes space that's not usable for PCI devices [1]:<br>
<br>
E820: [mem 0xdceff000-0xdfa0ffff] reserved<br>
PNP0A08 _CRS: [mem 0xdfa00000-0xfebfffff]<br>
<br>
Note that [mem 0xdfa00000-0xdfa0ffff] is included in both the E820<br>
entry and _CRS.<br>
<br>
If Linux assigns [mem 0xdfa00000-0xdfbfffff] to a PCI device, the<br>
system doesn't resume correctly from suspend. If Linux avoids the<br>
[mem 0xdfa00000-0xdfa0ffff] area and instead assigns<br>
[mem 0xdfb00000-0xdfcfffff], resume works correctly.<br>
<br>
Example 2:<br>
<br>
_CRS includes space assigned to a "hidden" PCI device [2, 5]:<br>
<br>
PCI: 00:0d.0 10 base d0000000 limit d0ffffff mem (fixed) # BIOS log<br>
<br>
E820: [mem 0xd0000000-0xd0ffffff]<br>
PNP0A08 _CRS: [mem 0x80000000-0xe0000000]<br>
<br>
The 00:0d.0 device is assigned the [mem 0xd0000000-0xd0ffffff] space,<br>
but the device is hidden so the OS cannot enumerate it, so the OS<br>
doesn't know what space the device consumes.<br>
<br>
PLATFORMS SUPPLY E820 ENTRIES COVERING ENTIRE _CRS WINDOWS<br>
<br>
Some recent platforms supply E820 "reserved" regions that cover \
entire<br> PCI host bridge windows. If Linux excludes these E820 regions from \
the<br> windows, it cannot assign space to PCI BARs, which means hot-added<br>
devices don't work.<br>
<br>
Example 3:<br>
<br>
E820 has a "reserved" region that completely covers the 32-bit \
MMIO<br> window from _CRS [3]:<br>
<br>
E820: [mem 0x4bc50000-0xcfffffff] reserved<br>
PNP0A08 _CRS: [mem 0x65400000-0xbfffffff]<br>
<br>
Historically, Linux has avoided putting PCI devices in E820 reserved<br>
regions to avoid the problems in examples 1 and 2. Avoiding those<br>
regions in this case means Linux can't assign space for hot-added<br>
devices, so they don't work.<br>
<br>
LINUX PLANS<br>
<br>
As far as I know, the ACPI spec does not require an OS to exclude space<br>
from _CRS resources based on the E820 memory map, and these conflicting<br>
requirements make it impractical for Linux to do so.<br>
<br>
The "avoid E820 regions" workaround worked for several years, but it \
no<br> longer works because of platforms that advertise E820 regions that cover<br>
*entire* _CRS windows.<br>
<br>
We plan to make Linux stop excluding E820 regions from _CRS resources for<br>
platforms with a BIOS date of 2023 or newer, so new platforms or new BIOS<br>
releases that rely on excluding E820 regions may break [6].<br>
<br>
Linux is likely to be broken on future versions of these platforms unless<br>
the firmware updates _CRS methods.<br>
<br>
If these platforms do not update _CRS methods to be complete and<br>
accurate, Linux may not boot. The user's options are to:<br>
<br>
- Manually boot with a kernel command line option like \
"pci=use_e820".<br> <br>
- Wait for an updated kernel with a platform-specific workaround.<br>
<br>
WHY DOESN'T THIS AFFECT MICROSOFT WINDOWS?<br>
<br>
Short answer: I suspect it *does*, but it's less likely to be a problem<br>
on Windows.<br>
<br>
As far as I know, Windows does not exclude MMIO space from _CRS based on<br>
the E820 memory map. But Windows allocates PCI BARs from the top down,<br>
while Linux allocates from the bottom up. Most of the issues happen with<br>
space at the bottom of the _CRS MMIO windows, so Linux is more likely to<br>
trip over them than Windows is.<br>
<br>
REFERENCES<br>
<br>
[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=2029207" rel="noreferrer" \
target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=2029207</a><br> [2] <a \
href="https://lore.kernel.org/linux-pci/4e9fca2f-0af1-3684-6c97-4c35befd5019@redhat.com/#t" \
rel="noreferrer" target="_blank">https://lore.kernel.org/linux-pci/4e9fca2f-0af1-3684-6c97-4c35befd5019@redhat.com/#t</a><br>
[3] <a href="https://bugzilla.kernel.org/show_bug.cgi?id=206459" rel="noreferrer" \
target="_blank">https://bugzilla.kernel.org/show_bug.cgi?id=206459</a><br> [4] <a \
href="https://bugzilla.kernel.org/show_bug.cgi?id=16228" rel="noreferrer" \
target="_blank">https://bugzilla.kernel.org/show_bug.cgi?id=16228</a><br> [5] <a \
href="https://review.coreboot.org/plugins/gitiles/coreboot/+/dbcf7b16219d%5E%21/" \
rel="noreferrer" target="_blank">https://review.coreboot.org/plugins/gitiles/coreboot/+/dbcf7b16219d%5E%21/</a><br>
[6] <a href="https://git.kernel.org/linus/0ae084d5a674" rel="noreferrer" \
target="_blank">https://git.kernel.org/linus/0ae084d5a674</a><br> </div></div></div>
_______________________________________________<br>
coreboot mailing list -- <a href="mailto:coreboot@coreboot.org" \
target="_blank">coreboot@coreboot.org</a><br> To unsubscribe send an email to <a \
href="mailto:coreboot-leave@coreboot.org" \
target="_blank">coreboot-leave@coreboot.org</a><br> </blockquote></div>
</blockquote></div>
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic