summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorBjorn Helgaas <bjorn.helgaas@hp.com>2010-12-16 10:38:56 -0700
committerJesse Barnes <jbarnes@virtuousgeek.org>2010-12-17 10:01:24 -0800
commit4dc2287c1805e7fe8a7cb90bbcd44abee8cdb914 (patch)
tree6ed67b382f15b16a9c9d7aca411fc7c13f2918b1 /include
parent30919b0bf356a8ee0ef4f7d38ca8ad99b96820b2 (diff)
downloadop-kernel-dev-4dc2287c1805e7fe8a7cb90bbcd44abee8cdb914.zip
op-kernel-dev-4dc2287c1805e7fe8a7cb90bbcd44abee8cdb914.tar.gz
x86: avoid E820 regions when allocating address space
When we allocate address space, e.g., to assign it to a PCI device, don't allocate anything mentioned in the BIOS E820 memory map. On recent machines (2008 and newer), we assign PCI resources from the windows described by the ACPI PCI host bridge _CRS. On many Dell machines, these windows overlap some E820 reserved areas, e.g., BIOS-e820: 00000000bfe4dc00 - 00000000c0000000 (reserved) pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xdfffffff] If we put devices at 0xbff00000, they don't work, probably because that's really RAM, not I/O memory. This patch prevents that by removing the 0xbfe4dc00-0xbfffffff area from the "available" resource. I'm not very happy with this solution because Windows solves the problem differently (it seems to ignore E820 reserved areas and it allocates top-down instead of bottom-up; details at comment 45 of the bugzilla below). That means we're vulnerable to BIOS defects that Windows would not trip over. For example, if BIOS described a device in ACPI but didn't mention it in E820, Windows would work fine but Linux would fail. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=16228 Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud