Message-ID: <51f3faa70912151614w30d1839cq66e8673ee5712e55@mail.gmail.com>
Date:	Tue, 15 Dec 2009 18:14:52 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Bjorn Helgaas <bjorn.helgaas@...com>,
	Yinghai Lu <yinghai@...nel.org>,
	Tvrtko Ursulin <tvrtko@...ulin.net>,
	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Are these MTRR settings correct?

On Tue, Dec 15, 2009 at 3:09 PM, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> On Tue, 15 Dec 2009 14:50:44 -0600
> Robert Hancock <hancockrwd@...il.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists