Message-id: <46F588D7.2030109@shaw.ca>
Date:	Sat, 22 Sep 2007 15:27:51 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Yinghai Lu <yhlu.kernel@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>, Andi Kleen <ak@...e.de>,
	rajesh.shah@...el.com, jbarnes@...tuousgeek.org, greg@...ah.com,
	patches@...-64.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [9/50] i386: validate against ACPI motherboard resources

Yinghai Lu wrote:
> On 9/22/07, Robert Hancock <hancockr@...w.ca> wrote:
>> Thomas Gleixner wrote:
>>> On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
>>>> Yinghai Lu wrote:
>>>>> No!
>>>>>
>>>>> MMCONFIG will not work with acpi=off any more.
>>>> I don't think this is unreasonable. The ACPI MCFG table is how we are
>>>> supposed to learn about the area in the first place. If we can't get the
>>>> table location via an approved mechanism, and can't validate it doesn't
>>>> overlap with another memory reservation or something, I really don't
>>>> think we should be using it.
>>> We all know how correct ACPI tables are. Specifications are nice,
>>> reality tells a different story.
>> MMCONFIG can't be used without ACPI in any case unless we know where the
>>   table is using chipset-specific knowledge (i.e. reading the registers
>> directly). Doing that without being told that this area is really
>> intended to be used, via the ACPI table, is dangerous, i.e. we don't
>> necessarily know if the MMCONFIG is broken on the platform in some way
>> we can't detect.
> 
> the BIOS get these info from the chipset too.
> for AMD Fam 10h opteron, we can read that MSR for MMCONFIG base.
> 
>>>> I don't think it's much of an issue anyway - the chances that somebody
>>>> will want to run without ACPI on a system with MCFG are pretty low given
>>>> that you'll end up losing a bunch of functionality (not least of which
>>>> is multi-cores).
>>> acpi=off is an often used debug switch and it _is_ quite useful. Taking
>>> away debug functionality is not a good idea.
>> If someone has to turn ACPI off, disabling MMCONFIG is probably the
>> least of their worries..
> 
> MMCONFIG has nothing to do ACPI..., just becase MCFG in the ACPI, we
> must use ACPI for MMCONFIG?

config PCI_MMCONFIG
          bool
          depends on PCI && ACPI && (PCI_GOMMCONFIG || PCI_GOANY)
          default y

We already depend on ACPI for MMCONFIG support at compile time. This 
patch does not change that.

We could conceivably skip the validation if ACPI was disabled, though 
this would only make a difference in the few cases where we can detect 
the MMCONFIG area without it (looks like currently only Intel E7520 and 
945, at least in mainline).

> 
> For AMD Fam 10h opteron, because using MMCONFIG need via %eax, so BIOS
> will stilll stay with MCFG entry for MCP55 SB to not break other
> os..., then you can not access ext config space for NB...
> 
> with enabling MMCONFIG in NB, and read NNCONFIG BASE from NB,( via
> pci_mmcfg_check_hostbridge) that we get full MMCONFIG access for NB...
> 
> Anyway this patch alter the feature...
> 
> BTW if you trust MCFG in ACPI so much, why do you need to bother to
> verify that in DSDT...

One reason is that Windows pre-Vista does not use the MCFG table, it 
does use the ACPI reserved resources. Since the board/system 
manufacturers have been testing against Windows, the resource 
reservations should be more likely correct than the MCFG table which was 
not used until Vista came along.
-
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