Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

Tony Camuso
2008-01-14T03:30:27Z

To all ...

Well, here is what I perceive we've got so far.

. Some PCI Northbridges do not work with MMCONFIG.

. Some PCI BARs can overlap the MMCONFIG area during bus sizing.
It is hoped that new BIOSes will locate MMCONFIG in an area
safely out of the way of bus sizing code, but there can be
no guarantees.

. conf1 is going away in newer x86 implementations in the not
too distant future.

. The PCI express spec requires platforms to provide access to
the extended config area, and there are express devices today
using that area for AER.

. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the devices. PCI config mechanisms only need to differ at
the Northbridge level.

. We have a flurry of patches all claiming to solve all or some
of these problems.

Arjan,

I realize it may not be possible for you to answer this question,
but I feel compelled to ask it anyway. Is it possible that future
x86 architectures will be implementing a SAL-like interface to
abstract PCI config access altogether?

Or can we condense these patches down to a set that does the
following?

. If the system is capable of conf1, then PCI config access
at offsets < 256 should be confined to conf1. This solution
is most effective for existing and legacy systems.

. If the system does not support MMCONFIG, of if MMCONFIG is
not working, then accesses to offsets > 256 return -1 and an
error status.

. For systems, where the conf1 mechanism is NOT available,
then MMCONFIG should be the PCI access mechanism for all
offsets. For such systems, we must assume that the BIOS has
become smart enough to locate MMCONFIG in a region safe from
encroachment by bus sizing code.