-
Bjorn Helgaas authored
Normally we reject ECAM space unless it is reported as reserved in the E820 table or via a PNP0C02 _CRS method (PCI Firmware, r3.3, sec 4.1.2). 07eab090 ("efi/x86: Remove EfiMemoryMappedIO from E820 map"), removes E820 entries that correspond to EfiMemoryMappedIO regions because some other firmware uses EfiMemoryMappedIO for PCI host bridge windows, and the E820 entries prevent Linux from allocating BAR space for hot-added devices. Some firmware doesn't report ECAM space via PNP0C02 _CRS methods, but does mention it as an EfiMemoryMappedIO region via EFI GetMemoryMap(), which is normally converted to an E820 entry by a bootloader or EFI stub. After 07eab090, that E820 entry is removed, so we reject this ECAM space, which makes PCI extended config space (offsets 0x100-0xfff) inaccessible. The lack of extended config space breaks anything that relies on it, including perf, VSEC telemetry, EDAC, QAT, SR-IOV, etc. Allow use of ECAM for extended config space when the region is covered by an EfiMemoryMappedIO region, even if it's not included in E820 or PNP0C02 _CRS. Link: https://lore.kernel.org/r/ac2693d8-8ba3-72e0-5b66-b3ae008d539d@linux.intel.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=216891 Fixes: 07eab090 ("efi/x86: Remove EfiMemoryMappedIO from E820 map") Link: https://lore.kernel.org/r/20230110180243.1590045-3-helgaas@kernel.orgReported-by:
Kan Liang <kan.liang@linux.intel.com> Reported-by:
Tony Luck <tony.luck@intel.com> Reported-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reported-by:
Yunying Sun <yunying.sun@intel.com> Reported-by:
Baowen Zheng <baowen.zheng@corigine.com> Reported-by:
Zhenzhong Duan <zhenzhong.duan@intel.com> Reported-by:
Yang Lixiao <lixiao.yang@intel.com> Tested-by:
Tony Luck <tony.luck@intel.com> Tested-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Tested-by:
Kan Liang <kan.liang@linux.intel.com> Tested-by:
Yunying Sun <yunying.sun@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Rafael J. Wysocki <rafael@kernel.org>
fd3a8cff