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

[Aaron Durbin]

On 11/8/06, Linus Torvalds <torvalds at osdl.org> wrote:
>
>
> 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.
>

I agree that the orignal patch was stupid in relying on the MCFG table reported
in ACPI, however, like you said, without the actual knowledge of the MCFG
region being pulled out of the hardware even the e820 check is not valid. It is
close, but not entirely correct. For instance, if the MCFG region is being
reported in ACPI land as 256 buses and the e820 has a reservation at the
MCFG base address of 18MB that does not necessarily mean the MCFG region allows
for PCI config access on 18 buses. It could be that it only allows 16 buses w/
another piece of hardware on that last 2MB.

So what is the proper scenario? One needs to know the actual upper limit of
MCFG region. Otherwise when detecting unreachable devices one could be poking
something else in the process of trying to discover these unreachable devices.
I am open to ideas and am willing to rework some of the code, but I do like the
idea of having the region being reported in the resource table.

-Aaron