Re: [discuss] Re: 2.6.19-rc4: known unfixed regressions (v3)

[ebiederm@xmission.com (Eric W. Biederman)]

Linus Torvalds <torvalds@osdl.org> writes:

> On Wed, 8 Nov 2006, Eric W. Biederman wrote:
>> 
>> The implementations I have seen, I believe have all been on bridges and
>> the maximum size is actually generated from the bus number below the bridge.
>
> Hmm. It might be possible to first set up the MMCONFIG thing for the 
> minimum range, then read the bus numbers from the host bridge on that bus, 
> and then expand the mmconfig range if necessary.
>
> Because pretty much ANYTHING is better than trusting the BIOS tables.
>
> That said, I'd really be a _lot_ more confident about it if we were to be 
> able to read the values from the hardware itself some way. There's 
> obviously a chicken-and-egg issue on mmcfg configuration, but it's one 
> that the BIOS startup code also has, so I assume that there is a solution 
> to that somewhere.

cfc and cf8 still work on x86.  So you can start with the old path
and then when you know mmconfig works you can upgrade.

In fact mmconfig doesn't necessary allow access to the entire pci domain.
On AMD systems currently you will get all of the subordinate busses but
the cpus themselves will not show up in the mmconfig space.

So we should have the infrastructure to only use mmconfig for some set
of busses.  If that interface is well described we can probably
bootstrap sanely, only enabling what we know exists and like wise
only reserving what we know is used.

For chipsets I know that there is quite a bit of information publicly
available.  For intel chipsets I believe those are registers they
make available in their public docs.  For things like the Nvidia
chipset the knowledge should be in the publicly available linuxbios
code base.

Hopefully that is enough of a pointer to get people going.  I might
have enough time to write the patch but I don't have enough time to
maintain it until mmconfig becomes boring.

Eric