Messages in this thread | | | Date | Tue, 15 Dec 2009 18:14:52 -0600 | Subject | Re: Are these MTRR settings correct? | From | Robert Hancock <> |
| |
On Tue, Dec 15, 2009 at 3:09 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > On Tue, 15 Dec 2009 14:50:44 -0600 > Robert Hancock <hancockrwd@gmail.com> wrote: >> I wouldn't have a problem with the E820 check being removed, since >> it's not actually reliable by itself anyway. In fact I'm not sure that >> we need any of the reservation checks at all. >> >> The whole reason we have this junk in there is because early on it was >> thought that a bunch of problems people were seeing with systems not >> working with MMCONFIG turned on were because their MMCONFIG was >> broken, and the reservation checks were there to try to weed this out >> by making sure the MCFG data pointed to a memory area that was marked >> as reserved. Originally it was checking E820 only, which turned out to >> be invalid because the firmware specification only told BIOS people to >> reserve the space in ACPI motherboard resources, not E820. >> >> Later on it was discovered that most of the problems were because we >> did all config-space access using MMCONFIG, including the base access, >> and combined with the fact that we don't disable decode on PCI devices >> when sizing memory BARs, the BAR location during sizing would overlap >> the MMCONFIG space and result in the device sucking up the MMCONFIG >> accesses, usually causing a lockup. So it wasn't actually due to any >> broken MMCONFIG motherboards at all. This was solved by using MMCONFIG >> for extended config space access only, so that when we move the BAR >> temporarily during sizing, we're not trying to access the MMCONFIG >> region it overlaps (since BAR sizing requires only base access). >> >> (Lesson: yes, BIOSes are broken a lot, but you can't jump to >> conclusions.) >> >> It would be interesting to know if there are any systems where the >> code reports the MCFG area is not reserved in the ACPI motherboard >> resources. I would tend to suspect not, because if it wasn't, Windows >> would potentially assign devices to that memory area on such boards >> and cause things to fail horribly, which presumably isn't happening. >> We might be able to just get rid of all that code. > > Yeah, that sounds like an accurate summary. I'd be in favor of ripping > out the e820 check (it's totally useless and just confusing) and moving > to using mmconfig for everything, not just extended space, provided we > disable decode around our BAR sizing (some bridges needed quirks there > though).
That may be viable, yes. Linus was opposed to the decode-disable last time he weighed in, though, although he did seem like he could be convinced if suitable exceptions were in place where it might break things..
> The ACPI resource checks seem harmless; as you say I'd expect every > machine running Windows to already have that part of the firmware > tested with the "Windows boots, ship it" validation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |