On Wed, 8 Nov 2006, Aaron Durbin wrote: > > 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. Oh, I agree. You'd _hope_ that the BIOS reports that as a separate region, and we could use that as a hint, but it's never going to be fool-proof. It's just much much better to try to figure out what the hardware itself thinks it is doing, rather than relying on a firmware engineer filling out the table to match what he _thinks_ the hardware is doing (or, more accurately, randomly scribbling values until Windows boots, at which point it's not his problem any more, and people ship the crap). Some misguided people used to think that we shouldn't do our own PCI probing, but use ACPI instead. This is the same thing, except on a smaller scale. MAYBE the scale ends up being so small that we can figure out some reliable way without actually asking the hardware itself, but I kind of doubt it. Especially judging by the current situation. > 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. Absolutely. I'd _love_ to have the region reported in the resource table. It's just that right now it doesn't seem practical, since the downsides are bigger than the upsides (and the upsides aren't _that_ big, since we require the thing to be marked reserved in the e820 tables anyway, so the resource tables do know about it, about as well as they currently can). In the absense of a way to actually ask the hardware, we could perhaps modify the thing so that it does request the regions in the resource table, but _only_ if the e820 entries aren't there (ie the "config type 1 didn't even work" case). Alternatively, we might choose to request just the known smallest region, because that should be relatively "safer". It's better than not reporting the regions at all, and while it's not perfect, it at least shouldn't have huge potential downsides from getting the size totally wrong... Hmm? Linus
