Olivier Galibert wrote:
On Sun, Apr 29, 2007 at 08:14:37PM -0600, Robert Hancock wrote:
-Validate that the area is reserved even if we read it from the
chipset directly and not from the MCFG table. This catches the case
where the BIOS didn't set the location properly in the chipset and
has mapped it over other things it shouldn't have. This might be
overly pessimistic - we might be able to instead verify that no
other reserved resources (like chipset registers) are inside this
memory range.
I have a fundamental problem with that: you don't validate a higher
reliability information against a lower one. The chipset registers
are high reliability. Modulo unknown hardware erratas and bugs in the
code (and accepting f0000000 is in practice a bug in the code, the
docs are starting to catch up with it too), the chipset *will* decode
mmconfig at the looked up address no matter what. On the other side,
the ACPI data is bios generated, and that is well known to be horribly
unreliable. Hell, if it was reliable we could just use the MFCG ACPI
table without questions.
So you can check the ACPI stuff for coherency (MFCG vs. the rest), you
can validate the ACPI stuff against the results of the lookup if you
want, but validating the lookup against ACPI is nonsensical.
The problem is that in the event the MMCONFIG table is assigned to an
address range that conflicts with other devices, there's no guarantee
that MMCONFIG will have the higher decode priority. Apparently this is
exactly the case on some boards, the MMCONFIG is mapped on top of
chipset registers, and when we think we're accessing the MMCONFIG table
we're really scrambling random chipset registers and hosing things. So
we can't just blindly trust the values as being usable even when they
come directly from the chipset.
As I mentioned, though, really what we want to verify in this case is
that no other reserved resources fall inside the range being decoded by
the chipset. I may see if I can code something to do this. Essentially,
though, the existing patch effectively does this, on the assumption that
the board won't have conflicting reserved resources in the ACPI tables,
which is probably a safe assumption as Windows would likely be terribly
unhappy with that..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
